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ABSTRACT 


This master’s thesis introduces the program management and 
concept of operations of the TINYSCOPE Program. TINY SCORE 
1s a 6U CubeSat designed as a low-cost and easily 
replaceable imaging spacecraft that can produce tactically 
relevant imagery data. Tactical requirements in this 
context would emphasize “good enough” image resolution with 
a rapid-response tasking loop and high revisit rate. The 
TINYSCOPE project intends to demonstrate the utility of 


small, risk tolerant spacecraft for tactical imagery. 


The program management section of the thesis discusses 
the relationships of cost, performance, risk, and schedule 
and the impact of each on the program. The program’s 
successes and failures are examined to glean lessons for 
future program managers of university projects. The 
remainder of the thesis develops a comprehensive concept of 
operations for the prototype spacecraft. Areas Or 
discussion include overviews of the ground, space and 
launch segments of the mission architecture, and proposed 
conduct of operations for those segments. Finally; 
relevant program management and systems engineering 


documentation are presented as appendices. 
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A INTRODUCTION AND BACKGROUND 


A. PURPOSE 


This master’s thesis discusses the program management 
and: -GOnCEpL -OF “Operations of the <=TINYSCOPE Program: 
TINYSCOPE’ iS .a2.. 6=unit CubeéSat, designed asa low-cost -and 
easily replaceable imaging spacecraft that can produce 
tactically relevant imagery data. Tactical requirements in 
this context would emphasize “good enough” image resolution 
with a rapid-response tasking loop and high revisit rate. 
The TINYSCOPE project intends to demonstrate the utility of 
small, risk tolerant spacecraft for tactical imagery. 

The program management section of the thesis will 
discuss the relationships of cost, performance, risk, and 
schedule and the impact of each on the program and on the 
Spacecraft design. The remainder of the thesis will 
develop a comprehensive concept of operations for the 
DPrOLOLYDe: Spacecrart. Areas of discussion will include 
overviews of the ground, space and launch segments, and 


conduct of operations for those segments. 


B. EVOLUTION OF OVERHEAD TACTICAL IMAGERY 
1. Early Attempts 


Information about a potential adversary’s actions or 
intentions provides a significant military advantage to a 
commander. Thus, it has long been sought after, often in 
wildly inventive ways. The use of overhead imagery to gain 
an aerial perspective has evolved from initially fruitless 
endeavors into a critical component of mission planning and 


execution at all levels of military operations. 


The earliest attempts to obtain aerial images were 
conducted by professional photographers using crude hot-air 
Dal lOoOns:. Gaspard Felix Tournachon applied for a patent 
for aerial survey after developing a picture depicting a 
bileds- eye: *Vilew Ob (Paris: am, ope eh) 

The military utility of this new technology was 
quickly appreciated and the Union Army Balloon Corps was 
created under the direction of Thaddeus Lowe [2]. At its 
peak, the Balloon Corps consisted of seven balloons capable 
of rising to over 1500 meters to allow “aeronauts” to draw 
maps and report on enemy activities through an on-board 


telegraph [3]. 





Figure 1. Thaddeus Lowe observing the battle from his 
balloon the “Intrepid” Fair Oaks, VA 1862. From [4] 


Enthusiasm for balloon reconnaissance waned by 1863, 


perhaps due to the inviting target that a tethered balloon 
2 


must have presented. The necessity for reconnaissance did 
not fade, however, and new techniques were developed that 
lessened the danger. Arthur Batut, a Frenchman, is known 
as the father of kite photography. His work, La 
photographie aérienne par cerf-volant, noted the potential 
for kite photography as a means to provide reconnaissance 
to militaries. By 1906, George Lawrence, an American, was 
using strings of kites to take panoramic photos of the 


devastation caused by the San Francisco earthquake. 





Figure 2. Ruins Of San FPrancisco G.1906. From [5] 


Other attempts to satisfy the demand for imagery 
bordered on the surreal. In 1908, Julius Neubronner was 
granted a patent for a miniature aerial camera designed to 
be strapped to a carrier pigeon. The camera and subsequent 
photographs were a hit at the Internationale 
Photographische Ausstellung in Dresden the following year 
cea 


Despite the various methods attempted to legitimize 
the developing field of aerial photography, the discipline 
did not gain widespread acceptance until the invention of 
the airplane and the World War that soon followed. 
Reconnaissance pilots flew countless missions over enemy 
trench lines to photograph the locations of men, gun 
emplacements, and materials. By the end -of World War 11, 
aerial photography emerged as a critical capability for 


strategic planners. 


2: CORONA 


With the advent of the Cold War came the need to 
determine the strategic capabilities of the Soviet Union. 
The CORONA program was designed to fulfill that need. The 
program became the first operational space reconnaissance 
platform on August 18, 1960. CORONA was a joint program of 
the Central Intelligence Agency and the United States Air 
Force. Over the decade long life of the program, CORONA 
gathered photographic images of more than 600 million 
square nautical miles of the earth. Images ranged in 
resolution from 25 feet at the beginning of the program to 
six feet as the program drew to a halt. The CORONA program 
is frequently showcased as an example of how a technology 


can revolutionize an industry [7]. 


UNWAY 


>< pk bees yet 


R 


18 AUGUST 1960 IMAGERY 





. 
eal 


Figure 3. First imagery recovered from CORONA, Mys Shmidta 
Air Field, USSR. From National Reconnaissance Office. 
5. Current Technology 


Satellite technology has continued to evolve since 
CORONA. Current commercial satellites are capable of 
producing images of nearly a million square kilometers per 
day. Options include multispectral images or panchromatic 


shots at resolutions of less than one-half meter. National 


imagery collection systems are undoubtedly capable of the 
same feats. Unfortunately, while technology has allowed us 
to take more and better pictures, physics still dictates 
that a single satellite ais unlikely to be able to 


photograph the same location on earth more than a few times 


per day. 
C. TINYSCOPE PROGRAM 
1. Background 


Strategic intelligence has traditionally been the 
focus of imagery collection, particularly space-based 
COLLeCELOm, However, as threats have evolved from peer 
competitor states to more regional, imagery requirements 
have adapted as well. Operations DESERT SHIELD and STORM 
witnessed a shift to operational ISR to allow theater 
campaign planning. The trend continued toward lower 
echelon use of national imagery systems throughout the 
intervening period prior to the World Trade Center bombing 


ey ZOO. “eels 


Entry into Operations IRAQI FREEDOM and ENDURING 
FREEDOM further shifted the use of overhead imagery into 
the tactical realm. The use of Unmanned Aerial Vehicles 
(UAVs) has become ubiquitous even at the platoon level. 
Along with the UAVs has come a reliance on the availability 
of real-time imagery, and thus, a demand for responsiveness 


that national systems cannot meet. 


Blocker’s suggested solution is a constellation of 
imaging nano-satellites that would provide near real-time 
iMaging: Capebility to the. warktrghter [oe |l. The TINYSCOPE 


Program is an attempt to design, build, and fly a prototype 


nano-satellite similar to the one that Blocker envisioned. 
The project seeks to use the  CubeSat standard and 
commercial off-the-shelf hardware as much as possible to 
develop a low cost flight unit for flight testing and 


concept validation. 


2 CubeSat Standard 


CubeSat 1S a pico-satellite design standard that was 
developed by California Polytechnic State University and 
Stanford University in 1999. The standard defines size and 
mass PeEStriCcLe ons, as well as interfaces with the 
deployment system. A standard single unit (1U) CubeSat is 


a 10cm cube and has a mass of 1.33kg. 





Figure 4. LU Cubesar 


CubeSats are commonly expanded into a 3U form factor 
measuring 10cm X 10cm X 30cm [9]. Both form factors are 


typically launched using a standardized CubeSat deployment 
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system, such as the Poly Picosatellite Orbital Deployer (P- 
POD)... “Ihe “P=POD 18 <n: aluminum box with ad door and. spring 
mechanism that can accommodate up to three 1U CubeSats or a 
single 3U CubeSat. Upon receipt of a deployment signal from 
the launch vehicle, a non-explosive actuator (NEA) releases 
the door and allows the CubeSats to slide along a series of 
rails and eject from the P-POD [10].” The CubeSat design 
standard does not currently allow for alternative form 
factors based on the standard, however, a 6U design is in 


development by NASA Ames. 


3% Program Objectives 


The TINYSCOPE project intends to demonstrate the 
Utidaty -of -smald, risk tolerant spacecraft for this 
purpose. The objectives of the TINYSCOPE mission are 
stated below. 


a. The primary objective of the TINYSCOPE program 
1s facilitation of student education at the Naval Postgraduate 


SCHOO: y 


ion The second critical objective is to launch and 
operate one TINYSCOPE spacecraft capable of obtaining a single 
image of a newly tasked target along a predetermined low earth 


orbit and transmit image to a Known stationary ground station. 


er Another objective 1s to develop an attitude 
determination and control system to provide accurate and agile 


pointing for nano-satellites. 


d. Finally, it is desired to exploit advantages 
of CubeSat platforms. This objective will require the project 
to include small subsystems requiring minimal power, mass, 


volume, and cost to operate. 


Il. TINYSCOPE PROJECT MANAGEMENT 


A. SYSTEM DEVELOPMENT PLANNING 


Project Management may be represented as a discipline 
composed of two constituent parts: Systems Engineering and 
Project Planning and Control. Figure 5 depicts the 


activities, which together comprise the project management 


domain [ll]. In reality, the individual provinces may be 
considerably less distinct. In our case, the TINYSCOPE 
team does not have a dedicated systems engineer. Many of 


the tasks that would traditionally be performed by a 
dedicated systems engineer were instead added to _ the 


program manager’s responsibilities. 


PROJECT MANAGEMENT 


“Wark breesiodcann 





Figure 5. Systems engineering as a part of project 
management After [11] 


is Feasibility Assessment 


One of the first steps in the design of any new system 
is the analysis of feasibility. In the case of the 
TINYSCOPE program, this assessment was performed by Blocker 
and Litton [12]. Blocker broadly outlined the subsystems 
that would be required to develop a spacecraft bus, while 
Litton focused on the optical imaging payload. The two 
efforts were complementary; each defined required functions 
and interfaces for their respective components. Together 
they developed an initial system definition, top level 
requirements for the system, and showed that their proposed 


system was feasible given current technologies. 


Blocker defined the TINYSCOPE system to be a three- 
Axis Stabilized, bow search: orbit secellite wireh: an elect ro= 
optical payload. The attitude determination and control 
system (ADCS) would be used for stabilization and pointing. 
Attitude and location determination would be provided by 
OnoOCard. sun sensors <and: Star trackers. Attitude control 
would be performed by either reaction wheels or control 
moment gyroscopes. Imaging would be conducted on command 
from a ground station accessible by direct line of sight. 
The satellite would use a series of slew maneuvers to point 
to the targets and then point back at a ground station and 
transmit the images via a radio downlink. Power 
requirements for the satellite would be met using body 
mounted solar panels and batteries [8]. Litton described 
the payload as an axially mounted Cassegrain telescope with 
an on orbit focusing mechanism. Images would be captured 
using a COTS focal plane array, like those used in digital 


cameras [12]. 
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Blocker and Litton used the above system definition 
and the broad guidelines outlined by the Operationally 
Responsive Space Office (ORS) to develop a set of top level 
requirements for TINYSCOPE. These initial requirements 
Shown in Table 1, served as the foundation for the 


TINY SCOPE. program. 


Summary of TINYSCOPE and Argus Requirements 


Requirement Threshold Objective 

Mission |0C Sep 2011 ASAP note 1 
MMD ~yrs 1 2 note 2 
Storage Life 2 3 
Reliability confidence 80% 80% 
Revisit ~hrs 1 0.5 note 3 
Images ~per day 30 60 
Task-to-collect ~hrs 4 1.75 note 4 
Task-to-product ~hrs 4 2 note 4 
Data Storage ~orbits 2 3 
Orbit Sun-Synch 45 to Sun-Synch 

Imager footprint ~km*2 25 50 
Max Slew Angle 30 45 
NIIRS 3 4 
Spacial Resolution ~m 4 2.5 

TT&C = Operations MMSOC, AFSCN 


Imagery Downlink CDL, DCGS 


Notes: 1. Initial Operational Capability 
2. Mean Mission Duration 
3. Revisit requirement for Argus constellation, not individual satellite. 
4. Based on Mission Planning timelines. Allows tasking of satellite at 
beginning of final mission plans with product in time for brief 


Table 1. Initial TINYSCOPE Top-Level Requirements 
From [8] 
2. Early Management Efforts 


An important early step in the development of a system 
1S a description of the scope of the project. A statement 
of work (SOW) 1s typically used to document’ broad 
responsibilities, deliverables, and the work activities 


required in a given project. The SOW acts as a guideline 
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for the project and in some cases is a binding contract 
between the vendor and the customer. The TINYSCOPE 
program, like many university projects, does not have a 
defined customer. Instead, proposals for funding that were 
submitted to sponsoring agencies became the de facto SOW. 
Due to the annual nature of these funding proposals, the 
work defined in each is limited in scope to what is to be 
performed in the funded year. The changes in scope each 
year inevitably have an impact on cost and schedule, but 
seem to be a byproduct of the lack of stable, long-term 
funding from the sponsors and may also be an inherent part 
of the learning process for any team attempting to build a 
satellite for the first time. Continuity was maintained 
TON LOUG A focused meetings and a positive working 
relationship between the students on our team and our 


RAaCuLLYy aadvasers : 


Concurrent with the feasibility analysis being 
conducted by Blocker and. Litton an. “2007, TINYSCOPE ‘was 
being explored as a student research development project by 
Dr. Marcello Romano. Initial proposals for funding were 
limited in scope to numerical simulations and preliminary 
hardware testing for the TINYSCOPE attitude control and 
optical systems. Deliverables were equally limited; they 
Imcluded. Aces tude <Control calgorithns,; test, data for COTS 
Optical <cOmoponents: and: ‘a pProtouype micro-CMG. Shortly arrer 
the initial research proposal, the scope of the TINYSCOPE 
program was greatly increased. By the end of 2008, there 
were ideas to design, buaild sand: baunmeh a: -prolcotcype 
TINYSCOPE, Spacecrare. An engineering design unit was 
scheduled to be complete and functional by the end of 2009. 


The proposed flight prototype was scheduled to be ready for 
ile 


launch by the end of 2011. Efforts began immediately to 
find suitable COTS components and where necessary to design 


and test custom hardware subsystems. 


The compressed timeline and the lack of a dedicated 
systems engineer forced much of the documentation that 
would be expected in a project following accepted systems 
engineering practices to be curtailed. An exacerbating 
factor was the lack -O© ca. ‘standard format. £Or Systems 
documentation. As a Pes, the three fundamental 
priorities of project management, cost, performance, and 
schedule, “were. Often: GLErLCuUlLte tO -escertain or Tinalize, 
but this, too, 1S not unexpected for an inexperienced 
student team working its way through the complexities of 
such a project. Capturing as much as possible of what is 
learned each student cycle enables the next cycle to build 


on the experiences of the last. 


Cost estimation is tricky for even an experienced 
budget analyst and it should not have been surprising that 
Mae Peek estimates FOr the TINTS COPE program were 
ODL AMisS baey Blocker’s feasibility assessment estimated the 
COst for: <a. TINYSCOPE, satellite “co ‘be approximately S250k 
[8]. This number was used as the baseline cost estimate for 
the program. We failed to appreciate that Blocker’s 
estimate was intended to be a life-cycle cost of an 
individual satellite in a constellation of 360 satellites. 
In that case, development and operational costs were to be 
spread over the entire constellation. Our TINY SCOPE 
prototype would require the same development costs for a 
Single satellite, ballooning estimates by an order of 


magnitude. 
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Farly attempts to define requirements were vague and 
incomplete. The top-level requirements shown in Table 1 
along with a minimal set of derived requirements gleaned 
from Blocker’s feasibility assessment and shown in Table 2 
served as the program’s only requirements documentation 
well into the preliminary design phase. The requirements 
that did exist were peorly written and open tO 
misinterpretation. As a simple example, a top level 
requirement in Table 1 called for the Task-to-product time 
to be within four hours with an objective of two hours. 
This requirement may be interpreted as the time between 
when a Soldier submits a request for an image to the time 
an image is available to that Soldier. Alternatively, it 
may be interpreted as the time between the tasking of the 
satellite by a ground station and the time an image is 
transmitted. back to- The oround Station. In practwce, this 
vagueness made it very difficult for the student engineers 


to design or select subsystems. 
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Top Level to Subsystem Requirements 


* EPS (INITIAL power budget) 
— Subsystem: vall be mainte around 4 Watts max (Gomis, Payload, EPS, C&D / TTC) 
— MED sute ncluding sensors by exception (ADCS. Sun, Star IMU, Maz. GPS] 
— Glyde Space PICU 
* Structure 
— Gapabélty to bunch via P-Pod |CohPoly Requirement] 
© GU: Utilicing primerity COTS infrastructure jeweption payload & MED suite] 
= 3 > Wine Gutom pets 
— Pagload volume restricted to 1021033 om at bunch 
— inital mass budget total 10 ke 
* 35 ke Peyloed 
= Die BPS incsoks eney 
= 15 be AGC ec cereor 
* 153 ke Structure 
° ike Comms 
° Ihe CROW BTEC 
= Sie Cabling end Connectors 


* (C&DH : floating point processor... 

* Comms: Payload and command data, transmitreceive._._.._. 
* ADCS :.81 deg /sect+/-18 0. 

* Payload: Given 1 msexposure, provide 3m GRD...... 


Figure 6. Derived requirements for TINYSCOPE following 
internal Mission Requirements Review 


The initial schedule for TINYSCOPE, shown in Ficure 7, 
was far too aggressive for a student-led project of this 
scope. Optimistic assessments like this were common when 
the project began due to the inexperience of the team. 
Often we failed to fully grasp the difficulty of our 


undertaking and the environment in which we worked. 


Lo 


eae sh dl 


Create Spacecratt ($/C) Design 1, Tinyscope 1 Mon 10/27/08 = Fri 9/4/09 





Concept Architecture / Development Mon 10/27/08 Wed 11/26,08 a , , : ; : 

SiC DESIGH 4 SYSTEM FUNCTIONAL REVIEW (Internal) FritMae Fri 111408 ott : : : : : 
CRITICAL DESIGN DOCUMENTS (ALCH Thesis’) Fri12N98 Fri 12908 3 129 | : | | | 

HIEW* MISSION REQUIREMEIITS REVIEW Thu 3209 Thu 3/1209 : : op aie : : : | 
PRELIMINARY DESIGH REVIEW (Informal w/SSAG) Tue 38109 Wed 78/09 : : 2 eee Se : | | 

Develop SiC design (by subsystem) Mon 10/2708 =Mon 3/3009 —— ny : : : : 

Detailed Final Subsystem Design Mon 112109 Fri 4/17/09 : 2 —— 7, : | 
TIYSCOPE SIC CRITICAL DESIGH REVIEW Fianna Fri4N7i09 ee ee ee ee ee ©) ee 
Tinyscope Common Ground Support Equipment (GSE} Feasibility Researe Mon 14209 Mon 5/18/09 : , : ——— ay : , , 

Build Structural / MED Test Vehicles (STV) and Simulators Mon 1112109 Tue 5/2609 a EEE ; 
TINYSCOPE SIC IN PROGRESS REVIEW Fris2qm9 Fri 6/2903 fs ee ee ee eee 

Build SIC subsystems Mon 32309 Fri 724109 a — — —  —_ TY 

Qual Test $/C subsystems (as independently as possible) Mon 3/23/09 = Fri 7/24/09 P| SY : 
THIYSCOPE SIC I PROGRESS REVIEW Mon 71603 Mon 7.809 ee ; 7 a eT , 
Integrate Tinyscope Design 1 (EDU) Mon 6/1109 Fri 8/1409 a ee — TZ 
Qualify/Test Tinyscope Design 1 (EDU) Mon 85/09) Fri 8/26/09 : , : : : : , : | | — 
SYSTEM VERIFICATION REVIEW | PRODUCTION READINESS REVIEW Frigi409 Fri 9/4009 : : , oe | | : : : 404 


Figure 7. Initial TINYSCOPE Project Schedule 10 February 
Z009 


With the advantage of hindsight, it is clear that the 
TINYSCOPE program had many program difficulties from the 
outset. Most of these shortcomings can be attributed to a 
lack of experience and a failure to understand the 
importance of the systems engineering process in the 
development OF a SYVStem. some of the program’s 
shortcomings might have been averted with a rigorous 
documentation process. Other difficulties were created or 
impacted by the university environment. Many of these 
impacts will be explored further in the following section 
including the nature of our work force, infrastructure, and 


FuUNGdING. 


Despite its challenges and program difficulties, the 
TINYSCOPE project has proven to be a tremendous learning 
experience. The author has gained valuable experience as a 
program manager in an environment where mistakes were 
tolerated and treated as an educational opportunity. Many 


of the difficulties that have been examined in this chapter 
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may have been preventable, but that is often the nature of 
education. In any event, the lessons have been learned and 


will be documented here. 


B. PROGRAM MANAGEMENT CHALLENGES 
a ee Student Work Force 


A significant reality of any university program is the 
student work force. There are both advantages and 
disadvantages to the use of student labor for a satellite 
program, but it requires planning and continued management 
to optimize the tradeoffs. The primary advantage to student 
labor is the knowledge and experience gained by the 
student. Disadvantages ot SLUCEnE Labor include 
inexperience, frequent turnover, and limited availability. 
However, with proper management these disadvantages can be 


overcome or at least minimized. 


The chief objective of the TINYSCOPE program is to 
facilitate the education of the university’s student 
population. Due to this, it made practical sense that 
SlLucenis would perform the Ma JOri ty OL the tasks 
associated with the design, management, and construction of 
the satellite. On the TINYSCOPE team, individual students 
were responsible for the design, testing, and construction 
of individual subsystems of the satellite. Additionally, 
the team had a student responsible for integration of the 
subsystems and a student program manager. Frequent 
interaction between our team ensured that each participant 
gained understanding of a good portion of the breadth of 


satellite design. 
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The members of the TINYSCOPE team come from varied 
military and civilian backgrounds, but the overwhelming 
majority had not had prior experience in the - space 
IMGUSTEY « Instead the required knowledge and experience is 
Gaineo TLrom. the curraculum,. through selit=study,. through on 
the Job [ener aD ake i through hand-overs with previous 
students, and finally through interacting with permanent 
support engineers. Gaps sometimes occur when students join 
the development team before they have gained the requisite 
knowledge. A key to overcoming these situations is to 
understand the institutional knowledge and experience that 
1s available from professors, staff engineers, and support 
staff at the university and collaborating agencies. One of 
the most important lessons the author gleaned from this 
experience was to enlist the help and support of those 
persons early in the planning process. rE may be. pelo r at 
to identify the types of knowledge or support that will be 
required during the systems definition process and then 
list those who may be resources in planning documentation. 
THOSe ‘persons: Should. Then be encouraged. Lo atbend some or 
all of the team’s development meetings to provide their 
perspective and insight. Formalizing the relationship 
between the design team and external staff resources 
through documentation will help to capture any costs that 
may be associated with their involvement. Te twas seleo 
provide a starting point for new members of the team to 


SeGkK. assistance. 


Another possible drawback to uSing student labor is 
their high turnover rate. Members of our team average 
approximately one year on the team before graduating. Each 


time a member leaves there is a risk that not only his 
ils: 


experience will be lost, but also that any knowledge 
developed will disappear as well. Managing Tiransi toms: bo 
ensure that a member’s contributions are documented and 
that responsibilities are assumed by another member of the 
team is a significant challenge. It only took our team a 
Single mishandled transition to realize the importance of 
having a standard procedure for outgoing personnel to 
LO LOW. Ideally this procedure would be outlined in the 


program’s Project Management Plan. 


A final vital lesson that the author learned in regard 
to student labor is to never assume availability. Students 
join a satellite development team to be a part of something 
interesting that will have a lasting impact. At our 
UnAVersSity 2e 2S: a. voluntary act. Students will always 
have conflicts between classes, other projects, and non- 
school activities that will limit the time available for 
the project. There will also be periods of time when 
recruitment of students becomes difficult, causing the 
project. to stall. At one point in the £=TINYSCOPE 
development, we had five engineers one month and one the 
next. LE: AS. 2mporvant. ©O: account. for this factor “when 
establishing development timelines and work and meeting 
scnedules:. Development timelines that are merely 
aggressive in industry become unrealistic in aéestudent 
environment. One approach to resolve this dilemma, proposed 
for the first time in this thesis since the beginning of 
the TINYSCOPE project, is to establish task oriented 
metrics for measuring progress rather than a simple GANNT 


chart depicting start/stop dates. 
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2. Infrastructure 


Special facilities are typically required in order to 
conduct integration and testing of space systems [11]. 
These may include facilities Lor environmental and 
qualification testing, environmentally controlled areas for 
testing and integration, or specialized test-beds for 
subsystem testing. For the TINYSCOPE program, our team 
determined early on that we would require a contamination 
COnUrol Led environment Lor subsystem testing and 
integration, as well as final assembly. We also realized 
that we would require specialized equipment to test our 
attitude control system and optical payload. Environmental 
and @bls baba melershesikeyal testing would be performed using 
facilities available at the university. TO minimize our 
production timeline, we decided to develop or purchase the 
required test and integration facilities in parallel with 


design and development of the system. 


The contamination control procedures for the TINYSCOPE 
program are based on the sensitivities of the on-board 
instrumentation and risk tolerances for the program as 
defined in the Project Plan in Appendix A and _ the 
COnGaAMINne@tteon Conkrol) Piet: am Appendix «C, Generally, 
integration and assembly of the spacecraft subsystems will 
be accomplished a International Organization FOr 
Standardization (1SO) Class: © clean. rooms. -Ouxr “unaversicy 
had two such facilities; however, both facilities were in 
use by other projects during the TINYSCOPE planning phase. 
Our team determined that it was necessary to build our own 


facility in the Nano-satellite Advanced Concepts Lab 


ZA) 


(NACL). Our facility was completed at relatively low cost 


using commercially available equipment. 


A new three-axis attitude dynamics, navigation, and 
control hardware simulator will be used to test the 
hardware and the software components of the attitude 
control and determination system. The simulator consists of 
a pedestal supporting a hemispherical cup in which the ADCS 
system will be free floating using a hemispherical air 
bearing. The air bearing will allow the simulation of a 


Zero gravity environment. 


Development of an optical payload test bed had not 
begun at the time this thesis was written. There are, 
however, several requirements that such a test bed must 
meet. The test bed must be able to determine the accuracy 
of the telescope’s alignment with the focal array. dl craigs: 
can be done ina variety of ways, most commonly through the 
use of an interferometer. The. West. ed: shoula. callow 
determination of the payload to provide contrast. Ideally, 
the test bed would help to define the modulation transfer 
function of the telescope as well. The “ESSE. eC. should 
allow both the payload by itself and the entire system to 
be mounted and tested in a thermal environment similar to 
expected orbital values. Finally, the test bed should 
allow measurement of distortion caused by vibration of the 


spacecraft’s attitude control system. 


So. Funding 


To effectively manage a project it 1S important to 
COLPECTILY. Forecast both direct and indirect COSES 
throughout the project lifecycle. For. -the “TINY SCOPE 


project, the primary investigator chose to maintain control 
ZA 


of budgetary decisions to preserve fiscal partitions 
between separate but complementary research areas. These 
included the parallel development of test facilities and a 


separately funded nano-satellite attitude control system. 


As the student program manager, this limitation in 
budgetary authority had benefits. The amount of time and 
effort that was required for day-to-day management tasks, 
such as developing purchase orders was greatly reduced. 
Additionally, because the program manager did not have 
Visibility Of ‘Cravel, dabor, Or 2nGLrect. Costs “associated 
with the project, budgetary estimates were easily developed 


based on hardware costs only. 


However, there were also inherent disadvantages to 
this budgeting scheme. The experience and knowledge missed 
by not working through the complexities of the university’s 
accounting and CONnerace wig Drocess are Wale ask © 
understanding project management. Ownership of the project 
budget also forces the manager to balance the relationships 
between cost, SCHeCuAKe, and: performance: bo a. Oreacer 
degree. In principle, monetary or labor assets may be 
allocated to one subsystem that is behind schedule in order 
to bring the project back into compliance with the 
schedule. Choices between components that have marginally 
different performance or risk become much more meaningful 
and are likely to be more considered when the decision 


maker 1s responsible for the money being spent. 


4. Outreach 


One of the unique and most enjoyable aspects of being 
a student program manager is the opportunity to engage with 


OCReY Organ zarions,. LUSeteurlons, -auc: andividuale pursuang 
AZ. 


complementary ideas. Typical engagements may be broadly 
categorized as marketing, collaborative, or requests for 


Services. 


Marketing engagements are an opportunity for our team 
to generate interest for the project from our eventual 
customers, the warfighter. They are also used to gain 
feedback from the personnel who will ultimately use the 
imagery provided by the TINYSCOPE satellite. It 1S common 
for the student program manager to provide marketing 
presentations to service commands such as the Army’s Space 
and Missile Defense Command (SMDC) and to representatives 


of the Intelligence Community. 


Collaborative engagements are conducted to share ideas 
and foster relationships with other academic, civil or 
commercial entities that work in the small satellite 
community. Meetings may be conducted formally or informally 
with a single or multiple organizations. Our team 
considered the annual CubeSat Developer’s Workshop hosted 
by California Polytechnic State University to be an 


excellent forum for the exchange of ideas and perspectives. 


Requests for services may be for funding, technical 


assistance or launch and integration services. The 
TINYSCOPE program relies on funding from external 
government agencies to operate. The funding cycle is 


annual and does not usually allow fiscal assets to be 
carried over from year to year. This necessitates annual 


proposals to request additional research funding for the 


project. It also requires that periodic progress briefs 
are presented to sponsoring agencies. Launch services for 
scientific or experimental Department of Defense (DoD) 


As 


satellites are provided through the Space Test Program 
(STP) < The STP manifests experiments which either enhance 
or provide new capabilities to the DoD and that have been 
approved by the Space Experiments Review Board (SERB). The 
TINYSCOPE project has received annual approval as an 


eligible experiment since 2008. 


Cs SYSTEMS ENGINEERING EVOLUTION 


There iS a complex interrelationship between cost, 
performance, schedule, and risk that must be balanced 
effectively in a systems development program. Coste. sand 
schedule are directly linked; similarly, cost has direct 
linkage to performance and risk. As an example of these 
relationships assume that schedule and risk remain constant 
while performance requirements increase; the cost of the 
program will Dbrukely ancrease.. Performance, schedule and 
risk are all indirectly linked to each other through cost. 
The function of managing the relationships between these 
elements is the responsibility of the project manager. The 
key to success 1S appropriate planning and documentation. 
As I have already described, the TINYSCOPE program suffered 
from a tack of planning and -documentation irom its 
inception. This was apparent almost immediately after 
volunteering to be the program manager. Our team attempted 
several stopgap measures to keep the program on track but 
our inexperience was palpable. Figure 8 is an early 
attempt to manage our requirements gap. We developed key 
performance parameters with objective and threshold values 


to define the capabilities we expected of our system. 
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| KPP |Description jective | Threshold | Units | 
| 001 _[Missionlife(Designtifey nts 
| 002 [Reliability 8 
003 _learth imaging resolution (Sensor) fs ft lm 
| 003.a_|Assumingorbitaltitude SO | OO | km 
[-o08.<eteaive eld ofeiew > si 
Too8 [satelite Mass Satellite Mass tg 0 tg 
| 004. |Deployfromavailabledesign DSA fm 
006 — [Downlink Downlink tacticallyusableimagery ss—<—sSSSOCOSSS usable imagery a ee ee ee eee 
006.2 [Telemetry and Command up-ink/down-link __|__fTandorothersaT_{ __nest*__f 
| 006.b |PayloadDatadown-link |G TandorothersatT | NPS* | 
| 006.c_|Groundstationantennasize tm 
ony rial sew Manewer Seeds /gtasgmment 
| 007.a_|Numberoftargetsduringpass targets | 
| 007.b |Anglebetweentarget 8 deg (angle) _| 
0007.c _|tatitudebounds 5 deg (latitude) | 
oe least tg ag 
| 009 |Geolocation tf 00m 
| 010 |storageCapability 8H images | 


Note *- estimated capability orbit dependent: desired mission altitude vs mission life 
Note ** - assumed precedence during prototype increment 
Note *** -includes ground station acquisition and 4 target areas 





Figure 8. TINYSCOPE Key Performance Parameters July 2009. 


Development delays and frequent miscommunication among 
team members about responsibilities and interfaces remained 
Pprevalenc. As development continued, the author again 
realized that these measures were not enough, so in 2010, 
we began a systematic overhaul of the program beginning 
with a project plan, a reconstructed requirements document 


and a task oriented schedule. 


The TINYSCOPE project plan in Appendix A describes the 
work activities required to develop a flight prototype. Lie 
acts as the defining document for the program’s mission and 
objectives and describes the technical approach that will 
be used by the development team. It additionally defines 
criteria for minimum and complete success of the system 
upon launch, The document outlines the team’s management 
and product structure and provides a baseline schedule and 
budget estimation for the program. The project plan acts 
as a LOUNCa eC document LOE all other LINYSCOPRE 


documentation. 


Zo 


The Certification and Requirements Document in 
Appendix B describes all of the system’s bus, payload, 
mission and technology, and master satellite interface 
requirements. It additionally defines required tests and 
inspections for the system and describes the methods and 


analysis procedures for the test and certification program. 
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III. TINYSCOPE CONCEPT OF OPERATIONS 


A. MISSION ARCHITECTURE 
a Space Environment 


TINYSCOPE. will. conduct. mormal operations. ain. a- ‘low 
earth orbit. The ‘nominal orbit 2s: sun=synchronous and 
circular at an altitude of 400 kilometers. The natural 
environment at this orbit includes the gravitational 
fields, plasma, magnetic fields, energetic charged 
particles, Ga laceie cosmic rays, and meteoroids. An 


additional concern 1S manmade orbital debris. 


a. Perturbations 


The Earth-Moon system will perturb the TINYSCOPE 
spacecraft’s orbit due to eccentricity of the Earth-Moon 
orbit and the rotation of the Earth and Moon. The planets 
will also perturb the orbits with Jupiter and Venus acting 
as the primary sources. Additional sources of perturbation 
include solar radiation pressure and atmospheric drag. 
These perturbations will vary due to attitude changes of 


Ehe -spacecrart.. 


b. Plasma 


A spacecraft in a Low Earth orbit 1s subject to 
plasma environments due to both the solar wind and the 
geomagnetic tail. TINYSCOPE will operate within this 
extremely dynamic plasma environment risking damage from 
spacecraft charging, contamination, and interference with 
SOMmMun teat von and other electronic hardware due [Exe 


Sean i latvon and wave refraction. Ey pce. charged 


Za 


particles will have energies of a few hundred kilovolts. 
Differential collection of charge on the external surfaces 
of the spacecraft may lead to electrostatic discharge 
events and attraction of contaminants. Severe charging can 


also interfere with electronic systems. 


spacecraft single event effects total radiation dose surface plasma 
charging: degradation interference with 
spacecraft 
communication 


specific galactic ip solar solar i O+ scintilla 
cause cosmic i particle particle erosion -tion 
not 
appl applic- 
able 





Table i 


Table 2. Space Environment Hazards by Orbit From [13] 


C. Energetic Particles 


TINYSCOPE will be subject to the effects of 
energetic particles, or 10nizing radiation, produced by 
solar flares and coronal mass ejections, the geomagnetic 
tail, and galactic cosmic rays. The spacecraft will also 
encounter ionizing radiation trapped in the Van Allen belts 
and in particular the South Atlantic Anomaly. This 
1onizing radiation can cause several types of damage. 


These effects include measurable changes in properties of 
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semiconductors and a deterioration of the thermal radiation 
properties of materials due to the cumulative penetration 
of the particles. The energetic particles can also cause 
Single event upsets to microcontrollers and changes in the 
surface reflectivity and transmission properties of optical 
sensors. Energetic particles will also add noise to images 
due to direct impacts with the sensor. This effect will be 
measurably more pronounced during periods of high solar 
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d. Surface Degradation Hazards 


Low “Baril: sr bical atomic oxygen LS wo hly 
reactive and erodes the external surfaces of surface 
materials. Atomic oxygen 1S very damaging to surface 
optical properties while some coatings, such as silver and 
osmium, are seriously degraded resulting in material 
removal or surface roughness. UV degradation may occur as 
well due to the presence of ultraviolet and X-ray 
wavelengths. It is expected that some amount of sputtering 
will, e@eur but 2G 2s unlikely to 2imit. operation of the 


spacecraft. 


e. Orbital Debris and Meteoroids 


Orbital debris will be a major concern for the 
spacecraft. There are currently over 20,000 catalogued 
objects greater than five centimeters in diameter in the 
low earth orbit environment. Kinetic impacts with debris 
objects could potentially be fatal to the spacecraft. 
Expected mass of meteoroids will be between .001 and 1 


gram. 


Zo 


2 Space Segment Overview 
a. Payload 


The TINYSCOPE payload consists of an optical 
telescope and a focal plane array. The telescope is a 
Matsukov—-Cassegrain design with a spherical primary mirror 
and a slightly aspherical secondary mirror mounted near the 
focus of the primary mirror, as depicted in Figure 9. The 
secondary mirror includes a smaller meniscus corrector in 
the center that reduces off-axis aberration and narrows the 
field of view. The effective focal length of the telescope 
is 1.45 meters. The diameters of the primary and secondary 
mirrors are each 9.3 centimeters. The mirrors will be 
aligned and focused on the ground and do not have an 


onboard focusing mechanism. 





Figure 9. Light path of a Matsukov—-Cassegrain telescope. 


The Loca! plane array Consisces of a 4.8 


centimeter monochrome Complementary Metal Oxide 
Semi conductor (CMOS) housed in a Toshiba_Teli, machine 
vision camera housing. The planar array is 4096 pixels by 
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3072 pixels and each pixel is 6.0 micrometers square. Each 
pixel has a dynamic range of up to ten bits. The camera 
has an electronic shutter and is capable of capturing 25 


frames per second at full resolution. 


b. Spacecraft Bus 


The TINYSCOPE bus provides power to the focal 
plane array, attitude control, command and data handling 
and communications. The bus 1S constrained to be a 6U 
CubeSat form factor and subsystems are limited to one half 


of the overall volume as shown in Figure 10. 


ATTITUDE - 
DETERMINATION 






PAYLOAD 
ATTITUDE | 
CONTROL 


EPS 


C&DH/ —_— 
COMMUNICATIONS 


Figure 10. TINYSCOPE Volume Configuration 


(1) Electrical Power Subsystem (EPS). The 
EPS consists of the power controller, the solar arrays and 
the batteries. The power controller provides regulated 
power to the payload and bus subsystems. It conditions the 


power generated by the solar arrays, provides circuit 
cal 


protection, and monitors the battery state of charge. The 
sOlar -arrays' will use -GaAs solar cells -to ‘power the 
spacecraft. The battery will provide initial power to the 
spacecraft following launch and will provide power during 
normal operations when the spacecraft 1s not sun soaking. 

(2) Attitude Determination and Concre |: 
Subsystem (ADCS). The ADCS will provide location and 
attitude knowledge, momentum management and pointing 
control to support normal operations. Attitude and 
location determination will be provided by a combination of 
sun sensors, a Star tracker, an inertial measurement unit 
and an on-board Global Positioning System (GPS) receiver. 
Pointing control will be performed by reaction wheels. ie 
ADCS will control spacecraft slew maneuvers in response to 
commands from the ground station and to return the 
Spececrart, TO. a.-Sunm: ssOaking eater tude, Maqnelo-Lergquer 
coils will be used to dump momentum when the reaction 
wheels become saturated or in response to commands from the 
GEOund. Sraeion. 

(3) Thermal Control Subsystem (TCS). The 
TCS will be a passive radiation system. Tne: Spacecrare 
structure will act as a heat sink to collect thermal energy 
from subsystems. Heat will be radiated through flat-plate 
body mounted radiators. 

Command and Data Handling Subsystem (C&DH). 
The C&DH subsystem consists of the command and data 
processor, solid state data storage, and the cabling that 
provides connectivity to the other spacecraft subsystems. 
Tne -COmmanad. and. Gata processor ‘Controls the scpacecrare 
subsystems and manages the spacecraft state of health. The 


processor will compress collected images and segment the 
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data for transmission to the ground station. The data 
storage is used to store collected images and state of 
health logs between contacts with the ground station. 
Communications Subsystem. The communications 
subsystem provides two way communications for command 
uplink and telemetry and data downlink. The S-Band radio 
will operate at 2.4 GHz and will provide a data rate of 1.2 
Mbps through a directional antenna. A secondary omni- 
directional antenna will provide low rate communications 


for telemetry and commands during contingency operations. 


Se Ground Segment Overview 


The TINYSCOPE ground segment includes the Mission 
Operations Center, the ground station and associated 
networks. The Mission Operations Center (MOC) 1s 
responsible. for Tlrghu operations; ceactivity planning end 
data management. The ground Sslallon acts as the 
communications element of the ground segment. De Ground 
station 1S required to provide daily contact with the 
spacecraft to allow telemetry and data downlink and command 
uplink. Ground segment networks include the link between 
the ground station and the Mission Operations Center, the 


Naval Postgraduate School Intranet, and the internet. 


a. Mission Operations Center 


The Mission Operations Center consists of three 
operational elements: flight operations, activity planning 
and data management. The flight operations element 
communicates with and controls the satellite through the 


ground station. Activity planning and data management 
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interact with the end user of the TINYSCOPE product. 


Figure 11 shows how each element interacts with others. 


Mission Operations Center 


Flight Operations Collection Plan Activity Planning 


Data Management 





Figure 11. Mission Operations Center elements 


b. Ground Station 


The TINYSCOPE ground station will provide an 
intermittent link between the satellite and the flight 
operations element. Currently, we plan to utilize the 
ground station on the Naval Postgraduate School campus that 
was built for another NPS satellite project, the NPSATI1 
[14]. The ground station consists of a steerable antenna, 
a telemetry tracking receiver, high and low frequency 
synthesizers and computer hardware with orbit propagation 


software. A diagram of the architecture 1S in Figure 12. 
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The steerable antenna is a 3.048 meter in 
diameter mesh parabolic dish. The antenna’s beamwidth is 
between three and four degrees. The pointing accuracy is 
approximately two and one half degrees. The antenna has a 
maximum elevation of 90 degrees and azimuth limitations of 
374 degrees, which will create a keyhole effect as a 
satellite passes overhead, reducing contact times with 


flight operations [14]. 


The antenna steering is controlled by the 
telemetry tracking receiver, which locks onto the signal 
from the satellite. The receiver sends commands to a 
controller box, which then engages azimuth and elevation 
motors to move the antenna. The orbit propagation software 
predicts the satellite’s orbital position based on previous 
ephemeris to provide the antenna controller with an initial 
search position. 
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Cc: Ground Segment Networks 


The ground segment networks provide physical 
links between the mission operations center and the ground 
station and allow end users to gain access to archived 
images. The campus intranet will be used for the former 
purpose using existing cabling. Archived images will be 
placed in a database by the data management element and 


will be available via a web interface. 


B. OPERATIONS DESCRIPTION 
a Spacecraft Operations 


The TINYSCOPE satellite pointes Oy and takes 
panchromatic images of, specified locations on the earth 
and transmits the images to a ground station. Generally, 
the satellite will receive a command from a ground station 
to image one or more locations. The satellite will then 
calculate the necessary slew maneuvers to point to the 
specific locations, conduct a maneuver and record an image, 
and then continue to the next location. Upon completion of 
assigned missions, the satellite will slew back to point at 
the ground station and transmit the image data. Ground 
controllers also have the option to command that images be 
taken and stored for transmittal upon the next access to 
Ehe:. Oround. sStatzon: Finally, the satellite seeks a sun- 
soaking orientation when not performing a tasked mission. 
Fach of the subsystems plays a role in ensuring that the 


satellite can perform its primary function. 


a. Operational Modes 


The TINYSCOPE spacecraft has three operational 


modes. 
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NORMAL Mode is the standard operational mode for 
Gike: . Space Ccrares In this mode the spacecraft can perform 
image collection and all of the supporting tasks that are 


required. 


SAFE Mode provides a safe haven FOr the 
spacecraft when required by environmental conditions or 
anomalies. This mode is designed to allow the spacecraft 
to maintain limited FUNNEL LORIE yy: Dur still protect 
components from damage. In this mode, the spacecraft can 
no longer perform image collection. The payload and S-band 
radio are deactivated and the spacecraft seeks an 
orientation to allow the solar arrays full access to the 
Sun: The beacon radio transmits continuous telemetry data 
through ‘the -omna-directional -<antenne. Recovery from SAFE 


mode requires intervention from the ground. 


EMERGENCY Mode is used when the spacecraft is in 
IMMedtace Canger OF «ay Critvedl. Tarhure sor «mUsSsaon ending 
damage. All subsystems with the exception of the beacon 
radio are deactivated. The beacon transmits a periodic 
distress signal along with telemetry data to preserve 
power. The EPS deactivates, as well as provides a direct 
path from the solar array to the battery for charging. The 
spacecraft is not capable of image collection, high rate 
COMMUN Cation, OF -abratrude Control aon EMERGENCY (Mode. 
Recovery from this mode requires that the ground station 
intervene by sending a hardware command to the beacon radio 


to reactivate the processor and load a software update. 


oy 


lox Telemetry, Tracking, and Command (TTEC) 
Operations 

TINYSCOPE has two antennas, one directional and 
one omni-directional to transmit and receive TT&C data. 
The S-Band transceiver periodically transmits telemetry 
data through the omni-directional antenna regardless of the 
satellite’s position relative to the ground = station. 
Telemetry data includes position, orientation and state of 
health NIER Oselele1 40M. Di ekiagik are normal operations, the 
satellite will perform a slew maneuver to orient the high 
gain antenna towards the ground station thirty minutes 
PELOr “CO. GONEACE: and: Temarun an This atrtacude. It will then 
transmit a pulsed tone to allow the ground station antenna 
GO. Track. Upon. anata: -<GOntaet: with: The- Grounc: Station, 
the TINYSCOPE satellite will send recorded telemetry data 
to the ground station and then standby for command uplink. 
Command uplinks will include CLOCK Ssynehroni zation, 
authentication and a command = script. The, - Jonny SCOPE 
satellite will authenticate all command uplinks' before 


execution. 


Cc. Data Operations 


The TINYSCOPEK spacecraft has the capability to 
store three types of data. Command sequence data tells the 
spacecraft which missions and maintenance activities to 
COnGUCE: VEeLemMeuLry ~date. ere: Gathered. From @ace. Subsysrem: 
It is essentially a log of functions performed, system 
status and environmental conditions. Mission data are the 
images that the satellite collects. Fach type of data is 
stored in separate partitions on the solid state recorder. 


When the spacecraft is commanded to downlink stored data, 
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telemetry data are transmitted first followed by already 
executed and unexecuted command sequence data and then 
MLSsion. data. Individual images are treated as separate 
files by the spacecraft. Upon receiving acknowledgement 
that data has been received, the spacecraft will free the 
data to be overwritten on the solid state recorder. If a 
file is not acknowledged by the end of the contact, the 
spacecraft will retransmit the entire file at the next 


Contact. 


d. Pointing Operations 


The TINYSCOPE spacecraft 1s attitude stabilized 
in three axes by the ADCS subsystem. Position and attitude 
determination is performed continuously by the spacecraft. 
Pointing control of TINYSCOPE “1sS' provided autonomously by 
the spacecraft processor. The processor gathers data from 
attitude and position sensors and pointing commands from 
the ground, determines the required momentum adjustment and 


issues commands to actuators. 


Slews are vehicle maneuvers that orient the 
spacecraft to collect mission data, to communicate with the 
ground via the high gain antenna, and to orient the 
spacecraft for power management operations. The spacecraft 
uses momentum management to perform slew maneuvers. Slews 
may be initiated autonomously by the spacecraft or by 
command from the ground. A typical slew maneuver begins 
with a real-time or sequenced command to collect an image 
OL <a: Ground. target. The spacecraft will perform constraint 
checks for sun avoidance and then point to the calculated 
position on the earth’s surface and then settle. settling 


time allows the attitude determination subsystem to 
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reacquire position and attitude knowledge. Ene Spacec rare 
then uses fine momentum adjustments to maintain the target 
in the center of the image field and to null the effects of 
motion. Errors may be generated, if pointing to the target 
WOUld. Weoleace: <a “<COnSstrartnc, Of 2E the -<calculaced. is lew 
profile will cause the momentum stored by the reaction 
wheels to exceed predefined limits. io "hese: Gases, whe 
spacecraft will unload momentum by magneto-torquers prior 


to the maneuver or not execute the command. 


e. Power Management Operations 


Power management functions for the =TINYSCOPE 
spacecraft will be handled autonomously by the EPS 
subsystem. The power controller will regulate power to 
spacecraft subsystems. It will manage loads based on the 
Spacecrarte’ Ss operating mode and power profiles. The 
controller will also provide automatic charge of the 
batteries. When the spacecraft 1s not actively pointing 
for imagery collection or communications, the spacecraft 
will orient the solar array panels towards the sun to allow 


the batteries to charge. 


2:3 Ground Systems Operations 


The end user for the TINYSCOPE satellite will be the 


student and faculty population at the Naval Postgraduate 


SCHOOL. Imagery may be used for research in the field of 
remote sensing. Archived imagery may also be available to 
the general public through the internet. Generally, 


imagery will be requested through a proposal to the 
activity planning element, the flight operations element 


will generate the commands required to execute the proposal 
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and the data management element will archive, process and 
distribute the images. This sequence may be categorized 
into Pre-mission Operations, Mission Execution, and Post- 


Mission Operations. 


a. Premission Operations 


Premission Operations includes acculLyireres 
necessary to solicit, review and approve proposals for 
imagery, schedule mission and maintenance activities, and 


conduct long range planning. 


TINYSCOPE 1S expected to have excess capacity for 
image requests after commissioning and pre-planned proof of 
concept tests have been completed. ly tArS “rnstance, 
additional requests for imagery will be solicited. Research 
proposals from. NPS ‘students: and taculty will iwkely be 
accommodated first, but there may be an opportunity to use 
some of the excess capacity for Science, Technology, 
Engineering, and Mathematics (STEM) outreach programs with 


local *senools.. 


Regardless Of the source, proposals f£ Ox 
collection will contain basic information on the research 


objective, requested location, Constraints on viewing 


geometry and weather, and how the image will be 
distributed. The activity planning element of the MOC 
will conduct monthly boards to review proposals. The board 


will ensure that the requested image is not militarily 
sensitive and that it does not violate the Land Remote 
pensing -Poliey -Act. OF «1992. Proposals will then be 
Prueoritazea <ibeased. on requested Tame cComstraints. -and. -the 


board’s view of the proposal’s merit. Finally, the 
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prioritized list of proposals to be scheduled will be 
approved by the supervising faculty member and archived by 


the data management element. 


The activity planning element is also responsible 
for scheduling via the spacecraft mission plan and a 
detailed activity plan. Approved proposals and spacecraft 
maintenance activities will be scheduled in the mission 
plan based on priority and availability of appropriate 
viewing geometry. The mission plan identifies primary 
activities for the activity plan, special considerations or 


constraints, and viewing geometry. 


The mission plan is translated into an activity 
plan depicting resource allocation, event durations and 
times. The activity plan is a detailed minute by minute 
ordering of an event sequence. An activity plan, like the 
one shown in Figure 13, will go directly to the flight 


operations element for command sequencing. 





a@ STK Scheduler -[ TINYSCOPE Thesis] 


&y File Edit Yiew Resource Task Schedule Window Help 


D\ce|ta| SB] Ba] x |x| da) | | RIT COP) SIB/C!| & 2) 











: _ : Tasks 7 a : - 

Name ‘ Prhority Start Stop Duration Status Groups Resources Notes 

"T, Ground Communicatior| 5] a No NA Fecuning Dein “i aati -_ aes | pie: 
em Ground Conmricator| 8 |2010008715, 080828 [2CICABNS 087828 [O.defsLonTDOO [assed | —SSSSSSSC«*diNPS Gandia, Sold] 
Ground Commricator| ———S|2010TRTS_ 193699 [2UTOR. TEAS [O.defeLonTOOD —— [asiwred | SC*NPS Grandia] 
fe Gicund Commerce] ———S[zororoarie zr0a80  [2creoeris.217850 [o.dyfe,onva0 —— [Asswred | «NPS Ground Sites SoRd| 
a Gicundtommancater] IMAM MA tAed =| TTC 
SiondCanmricaio| —— S|zororeeie anaase [acrormaris 2os284  Odewteonta00 —[asiored | «(NPS Grund Slaton SOR] 
f= GrcundCommricaier| ———S|2OVOMORT7_O7aB12 —[2CIOABA7 C7512 |OdeyeLOoIa00 —[assored | CNS Grund Staion Sod] 
Gin Conmricator| ———S[eorareeria.cezens acicoeria.cace03 odwyeLonio00 asiored | «NPS Grandia. Sol] 
Ground Communicatior | S| 2010/08/18.19:49:46  |2010/08/18.19:59:46 |0_dayfs)_00:10:00 Assored =f NPS Ground Station, Sold PF 

fa GicundConmvicator| ——S|zororeigovetss acicvena.ceosse [odweonto00 [aired | —SSSC*(NPS Grund Slaton. Sokd| 
fe Greund Canmaicair| ———S|zOTOrOR7Ta mes 20 [2CICRTTaL 210620 [O-dafeLooTO0O ——(assmred | «(NPS Grund Stato. SoRd| 
Ground Canmricair| <5 [2ororoara0_orzez  [aciooereo.o7ve2t[o.defeyonva0 — [Asswred | «(NPS Ground Siates Sod 
ee GicwndConmaicater| ——Sororoermn_zoza32 acioearen 203932 [o.dyeLontow® —— |Asswed | (NPSGoundSiton Sol] 
Ground Communica] ———S[20r0roe/a1_orceusfacroroarzi_o7i20e [a.dweLoo1s00 — [asored |= Gen Staion Sok] 
finoe CanpPendetor| ——S|zoromeerie orcas [2crommais.o7as01  |odaieLonon1s  [asiored | =a Pendeton Now] 
finage Crnth-Stwed | S[20r0roeis osoKsT acionaris.o50606  odyeLovonis [assed |= SC*d minh Sod RateRecae| 
ince Gum-Stoed | S[eoranensvazate anions ze odweLovonis [assed |= SSCSC*dGuar Sond Steck = 
Image Guayaquil - Stor | S| 2010/08/15_04:55:33 |2010/08/15.04:55:48 |0._dayfs)_00:00:15 Assored =P Guayaquil, Solid State Rec a 
Image Kabul - Stored |_ B 2010/08/17_07:46:59  |2010/08/17_07:47:14 —|0_dayfs)_00:00:15 Assored ef Kabul, Sold State Recorde fF 
nese Nenous-Stoee| [2010/0877 ORSRH@[2UICORrI7_oxOOTS —|odaweLODODTS —[asiored |S SSS«iManaun Seid tec] 

Image Thue - Stored 5§|2010/08/21_04:08:15  |2010/08/21_04:08:30 [0 day{s]_00:00:15 Assigred Solid State Recorder, Thub 








Figure 13. TINYSCOPE Activity Plan 
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Long Range Planning is performed to optimize use 
of the spacecraft and minimize scheduling conflicts due to 


planned maintenance operations. 


b. Mission Execution 


The flight operations element of the Mission 
Operations Center performs mission execution functions. 
The activity plans that are generated by the activity 
planning element are converted into command loads for 
uplink to the spacecraft. Command loads may contain event 
commands, which instruct the spacecraft to collect an image 
of a specific location at a given time, or they may be 
system commands. System commands are instructions for the 
spacecraft €o perform a: non—-collection task. Examples of 
system commands include instructions to transmit stored 
data, acknowledgements that files are have been received, 


commands to unload momentum and the like. 


TINYSCOPE is being developed as a demonstration 
of immediately available satellite imagery tasking. This 
requires that event commands may be transmitted in real 
time and executed immediately. Real-time event commands 
are the primary type of command for the TINYSCOPE system. 
System commands may also be used real-time. When multiple 
real-time commands are sent to the satellite, they will be 
grouped into a real-time command script and transmitted as 


ar Dat-ch x 


It may also be necessary for the satellite to 
store cued commands to image locations that are not in the 
access footprint of the NPS ground station. in: Chas: case, 
a stored event command will be used. Stored command 


sequences are a collection of stored event and system 
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commands that will be executed at a later point. Fach 
command contains a time tag to tell the satellite processor 


at what time to execute the command. 


A final type of command that may be used is the 
software update command. Software update commands’ load 
updated databases or software patches to the satellite 
PEOCESSOr,. These might include updates to star databases, 


ephemeris tables or corrections to flight software. 


Regardless of the type of command that is being 
sent to the satellite, it must be reviewed and then tested 
on a software model of the fight system. Once a command 
sequence or real-time script has been validated, it will be 
given an authentication tag by the simulation software. 
Upon uplink the satellite will verify the authentication 
tag prior to executing any command. Validated and 
authenticated command files will be sent to the ground 
station computer and will be transmitted automatically 


following contact with the spacecraft. 


Cc. Post-Mission Operations 


Following a successful contact with the ground 
station, telemetry and imagery data that was broadcast by 
the spacecraft will be transmitted automatically to the 
flight operations element. Files will be checked for 


integrity and then relayed to the data management element. 


Engineering and telemetry data will be processed 
in the ie Oa operations element and simultaneously 
archived by the data management element. The flight 


operations element will analyze telemetry logs to monitor 
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the spacecraft’s state of health, discover anomalies and 


identify trends that may degrade operations. 


Mission data Woe, be passed to the data 
management element for processing and archiving. Raw 
copies of the image will be stored in a separate image 
database from images that have been processed. Images that 
were collected following an accepted research proposal will 
be provided to the researcher in raw format. Public access 
to processed images may be available via the internet at 
the discretion of the university. Raw data may also be 
made available for a fee to defray processing expenses. 
Occasionally the flight operations center will review raw 
images to identify CMOS pixels that are not functioning 
proper ly. Pixel information will be passed to data 


processors to aid in removal of incorrect information. 


Sx Launch and Early Operations 


Launch and early operations (L&KO) includes launch, 


activation: -ancd, Commissioning. 


a. Launch Operations 


Launch Operations begin at lift-off and end when 
the spacecraft has been ejected from the CubeSat deployer. 
CubeSats are typically secondary payloads and  Ilaunch 
opportunities in a particular orbit are not guaranteed. 
Secondary payloads have additional constraints that are 
required as well. During launch operations the spacecraft 
will be safed and unpowered. This requires that the 


spacecraft have a means of self-activation. 
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b. Activation Sequence 


The TINYSCOPE spacecraft will be activated by the 
release of a spring-loaded contact pin when it 1s pushed 
from the deployment assembly. Activation will initiate a 
sequence of events, as shown in Figure 14. Tae ri tae. 
events in the sequence are depicted in bold outlines and 
include: attitude stabilization, solar power generation, 


and: THALELatCiToOn. Of <kow rate communications. 


Cc: Commissioning 


Following activation, the TINYSCOPE spacecraft 
will enter a commissioning phase during which all of the 
spacecraft subsystems will undergo testing to ensure full 
operability and the payload will be powered on for the 
first time. The objective of commissioning is to achieve a 


status that allows normal operations. 


The first task in the commissioning phase is 
Jainang fine pointing control of ‘Ehe spacecrart. Tas 
requires several steps. Initially, the spacecraft will 
perform a series of predefined momentum adjustments to 
confirm and refine the spacecraft’s moments of inertia. 
The refined MOIs will be fed into the spacecraft control 
algorithms Chblnaakiale | a software update: The various 
instruments used for attitude and position knowledge will 
be calibrated and ephemeris will be updated. Finally, 
attitude control parameters will be finely calibrated by 
using a series of slew maneuvers that gradually increase in 


aggressiveness. 


A second task eleeche wat be pertormed 


Simultaneously during commissioning 1s verification and 


46 


Calibrati-0n of bus subsystems. Power generation, 
temperatures, and electrical loads will be monitored to 
generate baseline profiles for the spacecraft. Autonomous 
operations parameters, fault detection triggers, and fault 
response mechanisms will be updated as necessary based on 
the baseline profiles. Bit error rates will be determined 


ror the: spacecratit: to ‘ground: communsacatirons Janks as well. 


The final commissioning task 1S activation, 


checkout, and performance evaluation of the OpE Lead. 


payload. ACTAVaALLOM: will. @eCccur aruer ‘a, wali period. oO 
allow “OUuE=GassinGg “EO occur, The camera module will be 
powered and functional tests will be performed. Electronic 


calibration will be performed to ensure the health of the 
detection lines. Once the camera is determined to _ be 
operating properly, the spacecraft will be tasked with a 
series of reference missions to determine performance 
levels. These missions will use a variety of locations to 
measure pointing accuracy, uniformity of the CMOS detector 


response, and resolution. 
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Spacecraft Activation Sequence 


Cz NORMAL OPERATIONS 
1. Contact Scenario 
a. Objective 


This scenario describes the functions performed 
during a standard communications contact between the 
LINY SCOPE satellite and the ground station. These 


functions will be automated during nominal passes. 


b. Assumptions 

" This is a standard pass over the NPS ground 
station. Access time will be greater than 4 
minutes. 

7 Satellite ephemeris at ground station and 


on-board 1S accurate to within two and one 
halt degrees. 


7 Satellite beacon and o> band Ladd are 
operational. 
7 Command SCELDE has been developed, 


authenticated and has been received by the 
ground station computer. 


c. Description 


TRirecy -MInuees prbor TO contact. the “TINYSCOPE 
spacecraft will slew to point the high gain antenna at the 
GrOUNG, Seation: and’ will Maintain track. The. Ground Station 


antenna will steer to predicted contact point. 


Fifteen minutes prior to scheduled contact the 
spacecraft will begin to transmit continuous low rate 
telemetry data through the omni-directional antenna. The 
ground station antenna will initiate a sweep pattern to 


acquire the beacon. 


Upon acquisition of the beacon, the ground 


station will begin tracking and transmit a handshake 
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Signal. The spacecraft will maneuver as necessary and 
complete the handshake with the S-band radio and high gain 
antenna. The beacon will then cease to transmit. 
Following beandshake, The spacecraft will ‘pass real “time 
telemetry to the ground station. The ground station will 
upload a clock synchronization command followed by the 


authenticated command script. 


A typical command script will contain a command 
to initiate playback and a new command load. Playback will 
begin with the telemetry log followed by the command 
sequence data and mission data. Data will be packetized to 


protect against communications disruption. 


Ninety seconds prior to the contact keyhole time 
the ground station will send a command to halt playback and 
begin beacon operations. The handshake process will 
restart as the keyhole period ends and another playback 
command will be sent. This sequence will occur again at the 


end of the contact period. 


APLECL COmpoler Ton iof -plavyback ‘or J0OSs Of “COntace, 
the satellite will terminate the S-band transmission and 
resume normal operations. The ground station antenna will 
steer back to its stowed position and data will be 


transferred to the flight operations element. 
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d. Flow Diagram 
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Figure 15. Nominal Contact Scenario 
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2. Real Time Collection Scenario 
a. Objective 


The primary mission of TINYSCOPE is real-time 
image collection. This scenario describes the system’s 
performance when a real-time event command script 1s 


uplinked: Following Contact. 


b. Assumptions 


7 The im baae gales operations element has 
constructed an authenticated command load 
sequence that has been received by the 
ground SUCation. COmputcer + 


7 Spacecraft and ground station have performed 
handshake and spacecraft 1S prepared for 
command script uplink. 


Cc: Description 


The real time collection profile begins with the 
uplink of the command script to the spacecraft. Real time 
command scripts contain an immediate execution tag. Upon 
recognition of this tag, the spacecraft will terminate S- 
band transmission and resume low rate telemetry broadcast 
DY “Ehe “beacon: This allows the flight operations element 


EO: MONT tor ENS: mrssi-on. 


The spacecraft processor determines the required 


momentum adjustments to maneuver the spacecraft to point at 


the desired IP@Caka-On and executes the maneuver. 
Simultaneously the camera instrumentation will be 
activated. Ae ne. SpeceCralte. approaches, Ee <cOrEect 


orientation the adjustments become finer to allow the 
spacecraft to settle. Additional fine adjustments will be 


conducted during camera operation to reduce motion blur. 


a2 


The camera will record the target image onto the solid 
Stable LeCcorder:. The spacecraft will repeat this sequence 
for additional tasked images and then return to an 


orientation to communicate with the ground station. 


The S-band radio will be reactivated after the 
handshake with the ground station and the contact scenario 


will resume. 
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d. Flow Diagram 
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3. Programmed Collection Scenario 
a. Objective 


This scenario describes the system’s performance 


when a stored command sequence is uplinked following 


CONnGACE. 
b. Assumptions 
a The flight operations element has constructed 
an authenticated command load sequence that 
has been uplinked to the spacecraft. 
Cc: Description 
Execution of a stored command sequence begins 
after the termination of the contact scenario. The 


spacecraft begins by ordering the commands based on the 
time tags in the command sequence and discarding any 


commands that have expired. 


The spacecraft then identifies the command with 
the earliest time tag. If the time to event is greater 
than fifteen minutes, then the spacecraft will execute a 
maneuver to a esun-soaking orientation. Fifteen minutes 
prior to execution of a command, the spacecraft will begin 
momentum adjustments to point the spacecraft at the target. 
As the spacecraft approaches the correct orientation, the 
adjustments become finer to allow the spacecraft to settle. 
Additional fine adjustments will be conducted during camera 
operation to reduce motion blur. The camera will record 
the target image onto the solid state recorder. The 
spacecraft will repeat this sequence for additional stored 
events, returning ise) a Sun-soOaking orientation as 


allowable. 
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d. Flow Diagram 
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Figure 17/7. Programmed Collection Scenario 
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4. Momentum Management Scenario 
a. Objective 


This scenario describes the process required to 


unload momentum from the reaction wheels as they become 


saturated. 
b. Assumptions 
7 Momentum unloading may occur autonomously or 
as part of a command load. 
7 No image collection will take place while 
the spacecraft is unloading momentum 
C. Description 


The reaction wheels on the TINYSCOPE spacecraft 


will become saturated as the wheels reach their maximum 


spin rates. Momentum unloading will occur when = any 
reaction wheel becomes 80% saturated. Maqgneco-tOoLrquers 


will be used to dump the momentum. 


The momentum management scenario 1s started by a 


command from the ground or when telemetry indicates that 


the saturation threshold has been met. COLLEeCcEy on 
operations will be suspended. Stored commands will be 
reordered if possible. Real time commands will be 


discarded and an error will be annotated on the telemetry 


HOO. 


The maQqneto-=lLoOrgquer orthogonal LO the most 
saturated reaction wheel will be activated. That reaction 
wheel will then be decelerated to zero. This sequence will 
be followed by the next two reaction wheels. Following 


unloading, the spacecraft will resume normal operations. 
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d. Flow Diagram 
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Figure 18. Momentum Management Scenario 
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2 Software Update Scenario 
a. Objective 


This scenario describes the process of updating 
the spacecraft’s flight software. A software update may be 
required to correct a bug or to update the star tracker 


database or ephemeris tables. 


b. Assumptions 

7 The processor being updated is functioning 
proper lLy:. 

7 ihe software update has been Lested -on. the 


SOTtWwWarTe Simulator. 


7 Spacecraft and ground station have performed 
handshake and spacecraft 1S prepared for 
command script uplink. 


Cc: Description 


software uploads have the potential to be 
Catastrophic, The TINYSCOPE solid state recorder has two 
partitions dedicated to flight software integrity. The 
partition in which the current version of flight software 
being used by the processor resides is designated as the 
Primary Pareicton. The secondary partition alternately 


stores a past version of a future version. 


Software update procedures begin with the uplink 
of a preparatory command to delete the secondary partition. 
The new flight software is then transmitted to the 


spacecraft and stored in the secondary partition. 


Software update files are transmitted in packet 
segments that include cyclic redundancy checks (CRC) at the 
frame level. Additionally, a file checksum is used to 


compare the completed file on the spacecraft with that on 


ow 


the ground. If a CRC fails, the entire packet 1s 
retransmitted. it @. file ewhecksum, taads;. the entire tile 


will be retransmitted. 


Once the software update 1S in pace in the 
secondary partition and integrity checks have passed, a 
command to execute memory load will be transmitted. The 
update will be copied completely to the processor memory 
load buffer and integrity checks will be performed again. 
If a check fails the load buffer will be erased and an 
error report sent to the telemetry log and the ground 
station. If the integrity checks pass, the memory load 
will continue. After the memory load is complete the load 
buffer will be erased and a completion message will be sent 
to the telemetry log and to the ground station. The 
processor will then run a diagnostic self-test to ensure 
Fuld’ Toner Lonel ly., Upon successful completion of the 
test, the secondary partition will be designated as the 


primary and vice versa. 


If the processor fails a diagnostic test or the 
software is discovered to have errors, the previous version 
may be recovered from the secondary partition without 


contact with the ground. 
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d. Flow Diagram 
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D. CONTINGENCY OPERATIONS 
1. Fault Detection 
a. Objective 


The flight processor monitors each subsystem’s 
operational status to record in the telemetry log and to 
check for anomalies. If an anomaly is discovered, it may 
require the satellite to end normal operations to protect 
the subsystem from damage. This scenario describes how the 


processor monitors and examines the subsystems. 


b. Assumptions 


7 The spacecraft as operating sim normal 
operations mode. 


C: Description 


The flight processor automatically responds to 
anomalies on the spacecraft. The response to a given 
anomaly has usually been predetermined and tested prior to 
iP hbharen aye Anomaly responses are integral to the flight 
software and changes to responses will require a software 
Upagake. adn. “ne @Gyenl “thet .2n. anomaly ‘occurs tian. “Ene 
Spacecrarte -dees Not Have a programmed. ,response Dor, Ae 


processor will place the spacecraft in emergency mode. 


Anomalies that have been planned for may be 
responded to by taking the reporting subsystem offline, 
placing the satellite in safe mode or by simply reporting 
EMG: tanOmMewy ro: “Lhe GeLemertry. Lod: The severity of the 
anomaly will typically dictate the action taken. 


A subsystem may be taken offline when there is a 
condition that will cause further damage to the subsystem 


or the spacecraft if not corrected. An example of this 
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type of condition would be a temperature or voltage 
measurement that is too high or low causing a component to 


overheat or drain power from the spacecraft. 


The satellite will be placed in a safe mode when 
failure to respond will endanger the mission. This may 
occur when an anomaly involves more than a single subsystem 
or when the anomaly indicates that a reaction wheel of the 


Sspacecrarit 1S Out. Or Lames. 


Minor anomalies or pseudo-anomalies may require 
only that the anomaly 1S reported. Example cases of a 
report only anomaly may include failure of the battery to 
fully recharge or a slow rise or fall in temperature that 


1s creating a thermal imbalance. 


Anomalies that involve the safing Or the 
satellite or a subsystem must be resolved before normal 
operations can begin again. These anomalies will be 
analyzed by the flight operations element and corrective 
actions will be fully tested on simulator software before 


implementation. 
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Figure 20. Fault Detection Scenario 
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Spacecraft 

implements 

Emergency 
mode 


Zi Power Management Failure Scenario 
a. Objective 


This scenario describes the autonomous response 


OF the -<Spececrart. “when - the EPS: reports a low. power 


CONCLE LON 2 
b. Assumptions 
" The spacecraft nes operating ain normal 
operations mode. 
7 The EPS, solar array and batteries are fully 
Funct 16na.L. 
C. Description 


The EPS on TINYSCOPE continuously monitors the 
battery state of charge and the power drawn by the 
SPaceCraru 7s: “subsystems. A low power contingency may 
occur, if the spacecraft has been performing excessive 
attitude maneuvers in support of normal operations and has 
not maintained an orientation that allows power generation. 
When the batteries reach a low state of charge, a fault 
will be reported to initiate the automatic response. The 
spacecraft will cease to execute event commands and will go 
to SAFE Mode. The EPS will shunt all power to the 
batteries in an effort to allow them to recharge. The EPS 
will automatically restore normal power when the battery 


state of charge recovers satisfactorily. 


A more severe fault is generated if the state of 
charge continues to fall to a critical level. Pac, “te as 
point, the spacecraft will go to EMERGENCY mode. Recovery 
from EMERGENCY mode requires intervention from the flight 


operations element. 
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d. Flow Diagram 
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Figure 21. Low Power Scenario 
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3. Loss of Low-Rate Telemetry Beacon Scenario 
a. Objective 


This scenario describes the procedures taken when 
the low “ete telbemeury ‘ibeaccr fails wesuliing: an whe 
inabilaty LO. acquire a Sional. for the GS -antenna. to lock 


OnE O« 


b. Assumptions 
7 There 1s a scheduled contact with the ground 
Sitar Len. Spacecraft was operating normally 


during. Last. contac . 


7 Ground station antenna and computer are 
operational and pointing correctly. 


7 All other spacecraft systems are functioning 
properly. 
Cc: Description 


As in the contact scenario, the GS antenna will 
steer to and point at the location where the spacecraft is 
predicted to be. During a nominal contact, the antenna 
would acquire the beacon signal and use it to lock onto the 
satellite to enable high gain antenna communications. When 
the beacon signal cannot be located using the standard 


search pattern, this procedure is used. 


The flight operations element will verify that 
the GS 1S operational and is not at fault for the lack of 
aCouLls. con, Pointing angles will be recalculated and 
verified in the GS computer. Command logs from _ the 
previous contact will be examined to ensure that the 
problem was not induced by a command. Telemetry logs will 


be -revrewed tor anomalous conditions. and “to ensure Eehat 
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ephemeris data 1S correct. If the condition remains, the 


fault will be assumed to reside with the spacecraft. 


The GS will transmit a command to the spacecraft 
to activate the S-band transmitter and high gain antenna 
and commence downlink of telemetry data. This command will 
be repeated during subsequent passes until communications 
with the spacecraft 1S restored. Simultaneously, the 
flight operations element will begin developing a command 
load sequence to bypass the beacon and omni-directional 
antenna and utilize the S-band radio and high gain antenna 
for telemetry broadcast. Once communications can _ be 
restored, the alternate contact sequence will be used until 


lite -anome.Ly. “Gan: De <COLrPSCTed. 
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d. Flow Diagram 
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4. Loss of Command Ability Scenario 
a. Objective 


This scenario describes the procedures taken when 
the S-band radio or high gain antenna fail resulting in a 


loss of ability to command the spacecraft. 


b. Assumptions 


" The spacecraft Ms operating ain normal 
operations mode. 


" Beacon signal has been acquired and GS 
antenna is locked on the satellite. 


7 Last contact with spacecraft was nominal. 
c. Description 


The S-Band radio and high gain antenna are the 


primary means Om communication with the TINYSCOPE 
spacecraft. Should one or both fail, the spacecraft may be 
Commanded. ‘Through the low rave telemetry: beacon. It is 


also possible for the spacecraft to transmit mission data 
thzough the “beacon, but the Gate -retes: ‘would: be ‘Sub> 


optimal. 


During a nominal contact scenario, the ground 
station will lock onto the satellite using the beacon and 
then upload commands and download data using the S-band 
radio and high gain antenna. Indications that there is an 
anomaly with these components may come Enrough a 


Commins cations handshake taqckure. 


When an anomaly exists, the flight operations 
will first verify that the ground station is operational 
and is transmitting in the appropriate band and frequency. 


If the problem persists, a series of innocuous command will 
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be transmitted to the spacecraft to determine if the 
spacecraft can receive transmissions. The low rate 
telemetry being broadcast by the beacon should change based 


on the commands that were sent. 


In the event of a transmit only failure, the 
satellite will be commanded to downlink the telemetry and 
command sequence logs through the beacon and will be placed 
in SAFE mode. Anomaly investigation and fault recovery 


procedures will be implemented. 


A lack of change in the telemetry following the 
test commands indicates that there 1S a receive failure. A 
hardware command will be sent to the beacon radio to send a 
faut - COGS: sO, wie processor. The processor will then use 
its programmed response to deactivate the S-band radio and 
transmit and receive using only the beacon and omni- 
directional antenna. The satellite will then be placed in 
SAFE mode and anomaly investigation and fault recovery will 


begin. 
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E. INTEGRATION AND TEST 
1. System Integration and Functional Tests 


The TINYSCOPE satellite will undergo integration and 
testing in a Class 6 (ISO) clean room to ensure the 
spacecraft 1S not damaged by particulates. Equally 
important is that working in a clean room environment 
impresses upon students and others that the processes and 
activities are now such that a higher level of attention 
and consequence must be kept in mind while working with the 
hardware. Integration begins with the mating of the 
payload to the bus assembly and subsequent alignment. Mass 
models of the solar arrays will be added for some testing. 
This 1s Stage 1 for testing purposes. At Stage 1, the 
satellite will undergo a functionality test of all the 
mechanisms. The ADCS will be tested using simulated state 
vectors to ensure proper motion of the reaction wheels. The 
spring-loaded activation switch will be tested to ensure 
proper operation and solar array hinges and actuators will 
be tested. A telemetry check will be performed using 
Simulated data. The satellite will be placed in the three- 
axis simulator and control algorithms and moments’ of 
inertia for both deployed and non-deployed solar panels 
will be verified. Finally, the systems fault detection and 


responses ‘wild be Tested: using anduced Taulkts.~ 


The solar array panels will be integrated with the 
system for Stage 2 testing. During this stage, electrical 
interfaces will be verified and environmental testing will 


Occur. 


co 


Zi System Environmental Testing 


Environmental testing for the spacecraft will consist 
of thermal vacuum testing, electromagnetic interference 


testing (EMI), and random vibration testing. 


Thermal vacuum testing will be used to identify 
workmanship deficiencies under flight-like conditions and 


to screen for out-gassing and current arcing. 


EMIT testing will verify CONnpae LOL ey Or the 
subsystems’ radiated emissions. During this test, each 
subsystem will be operated in its most noisy state to 


determine interference with other subsystems. 


Random vibration testing will verify the system’s 
ability to withstand the vibroacoustic environment of the 
launch. it: will also help ‘ro -1dentity workmanship 


deficiencies [15]. 
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IV. CONCLUSION 


A. SUMMARY 


The program management and systems engineering 
challenges and lessons outlined in this thesis should be a 
useful guide for future projects at the Naval Postgraduate 
SCHOOL. In the author’s opinion, the success of a project 


is determined largely in the planning stage. 


A good program will have a clear end state and the 
milestones required to achieve that end will be defined in 
a framework document. System requirements must be clear, 
concise, and verifiable. Cost, performance, schedule and 
risks must be monitored continuously throughout the project 
and in accordance with the framework. this program: has 
been an excellent way to exercise the tenants of systems 
engineering and project management in an environment that 


fosters learning. 


B. FUTURE WORK 


The TINYSCOPE program has been an excellent learning 
experience. A tremendous amount of work has been conducted 


by the TINYSCOPE team, but much still remains to be done. 


There are several management functions of the program 
thee sta tl  ,eoqusare Giver 1 Ol. The Systems Engineering 
Management Piet will provide a Founda LON Or the 
implementation of the engineering effort by identifying the 
deliverables during each phase and defining the quality 
assurance plan and methodology for the project. iG: cuba sy 
outlines individual roles and responsibilities to ensure 


synergy among the work force. The Software Management Plan 


es 


defines the format of communications between the various 
subsystems: It will drive the development of the on-board 
algorithms, fault detection and recovery schemes, and 


authentication protocols for the system. 


A ground system still needs to be developed to manage 
COMMUNTCaLLons with the spacecraft, data management 
FUNCETONS;, and. Eiighic <eperat ons. The author hopes that 
development will be somewhat simplified by the effort given 


in this thesis to define the flow of operations. 


Finally, there is much work that remains in the design 
and development of the spacecraft bus and in the testing 
and integration of the various subsystems. Each of the bus 
subsystems and the payload will require environmental and 
FUNCETOnaL tests and will require MOdDEPOa tT LOS ee 
integrate with the spacecraft. The bulk of the command 
software and any processing software that may be used must 
be engineered and coded. Following integration of the 
subsystems, the satellite will have to undergo ae full 
battery of functional and environmental tests to ensure 


that it will operate as planned. 
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1 PROJECT OVERVIEW 


1.1 Introduction 

The TINYSCOPEK Project Plan describes the activities 
required to implement the flight of the technology 
demonstrator spacecraft. The TINYSCOPE mission will be 
conducted in a relevant space environment as defined for a 
Technology Readiness Level (TRL) of 8. TINYSCOPE will both 
demonstrate new spacecraft technologies and implement 
proven technologies. 


The TINYSCOPE project 1S primarily used as a vehicle 
for student research into attitude dynamics, guidance, 
navigation and controls algorithms and mission operations. 
Additionally, student researchers are gaining hands-on 
experience with design, construction and integration of 
satellite hardware. The current schedule plan 1s to 
deliver hardware ready to fly by December 2011. Due to 
the project’s size, scope, cost and schedule, the risk 
constraints for the project are somewhat relaxed when 
compared to traditional space CILIA ts As such 
Qualification testing is required only for verification of 
safety compliance and interface compatibility with the 


launch vehicle adapter. Acceptance tests will be conducted 
to ensure that critical performance parameters are likely 
to be achieved. Project reviews will be performed in the 


context of a technology demonstration test. 


1.2 Objectives 

TINYSCOPE 1s an effort to develop a low-cost and 
easily replaceable imaging spacecraft that can produce 
tactically relevant imagery data. Tactical requirements in 
this context would emphasize “good enough” image resolution 
with a rapid-response tasking loop and high revisit rate. 
The TINYSCOPE project intends to demonstrate the utility of 
small, risk tolerant spacecraft for this purpose. The 
objectives of the TINYSCOPE mission are: 


Pi The primary objective of the TINYSCOPE program is 
facilitation of student education at the Naval Postgraduate 
SCnOOL . 


By Launch and operate one TINYSCOPE' spacecraft 
capable of obtaining images of a tasked target along a 
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predetermined low earth orbit and transmitting images to a 
known stationary ground station within minutes of tasking. 


on Demonstrate an attitude determination and control 
system to provide accurate and agile pointing EOL 
nanosatellites. 


1.2.1 Performance Measurement System 
The methodology used for managing the =TINYSCOPE 
Project and measuring performance will be to monitor 


appropriate status indicators. Monthly updates reporting 
on risk data and the impact on mission success will be 
generacea and tracked. The following categories will be 


examined monthly for risk impact. 
Cost 


Fvaluate how the project budget is performing against 
the approved Project Plan budget and FY Actual vs 
Planned performance. 


Schedule 


Fvaluate how the project schedule is performing to 
ensure major milestones and the project delivery dates 
approved in the project plan are met. 


Technical Performance 


Fvaluate how the project 1S meeting the requirements 
documented in the approved project plan. 


Management Issues 


Evaluate management products/processes and other 
management responsibilities to ensure the project will 
meet commitments. 


1.2.2 Mission Success Criteria 
Objective 1 - Successful implementation and execution 
of the project plan including design, CONSELUCTLON, 
verification, launch, on-orbit evaluation and delivery of 
appropriate ground control hardware. 


Objective 2/3 - This system will have the ability to 
detumble and stabilize, point to earth and subsequently 
image and download to a ground station. 
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1.2.3 Extended Mission Success Criteria 
Objective 1 = successful completion of the 
development, test and integration activities results in 
hardware delivered for launch by December 2012. 


Objective 2 - Ability to download multiple images from 
a single orbital pass over the known ground station. The 
spacecraft will continue to operate and perform mission 
functions for a period of three months following launch. 


Objective 3 - Ability to quickly and accurately point 
to a specified location on the earth’s surface. 


1.3 Mission Description and Technical Approach 

TINYSCOPE 1S a unique spacecraft with experimental 
structural and pointing requirements, optics and software. 
Both the payload and bus will necessarily consist of 
technologies with various levels of maturity and space 
heritage. Therefore, wherever possible it 1s necessary to 
mitigate risks to operational success and to schedule by 
incorporating commercially viable components, with a 
preference for flight proven technologies. Development of 
unique subsystems will be considered on a case by case 
basis and will only be attempted when more mature options 
are not viable due to cost, performance or _ schedule 
constraints. TINYSCOPE will seek to exploit the advantages 
of CubeSat platforms by including small subsystems 
requiring minimal power, mass, volume, and cost to operate. 


1.4 Project Management and Team Structure 





Figure 24. TINYSCOPE Project Team Structure 
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1.5 Stakeholder Definition 
The objectives of the TINYSCOPE Project are intended 
to provide a demonstration of the capabilities that small 
satellites can provide to national security goals. The 
project is a direct offshoot of thesis work performed by 
Allen Blocker and Chance Litton intended to further the 


research into alternative national security space 
architectures. Therefore the customers Or TINYSCOPE 
LOG Loe: 


e National Reconnaissance Office 

e Air Force Research Laboratory 

e USSTRATCOM 

e Office of Operationally Responsive Space 


e External space technology R&D, commercial and academic 
organizations 
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2 PROJECT BASELINE 


2.1 Requirements Baseline 

The hardware shall be designed and built to meet the 
bus, payload, mission and technology, and master satellite 
interface requirements as documented in the Certification 
and Acceptance Requirements Document (CARD). The technology 
hardware shall be designed to meet the specifications for 
the interface requirements of the payload subsystem as well 
as the interface requirements of the Spacecraft Deployer 
and Launch Vehicle provider. Clarification of user 
requirements, operations, and driving technology will be 
performed prior to the Critical Design Review (CDR). 


2.2 Reference Documents 
The following documents are reference documents for 
this plan: 


Certification and Requirements Document NACL10-02-T 
Systems Engineering Management Plan NACL10-03-T 
Software Management Plan NACL10-04-T 

TINYSCOPE Master Schedule NACL10-05-T 

Mission Operations Plan NACL10-06-T 

Master Product Breakdown Structure NACL10-07-T 
Contamination Control Plan NACL10-08-T 

TINYSCOPE Request for Research Proposal to NRO 


2.3 Product Breakdown Structure 
The TINYSCOPE Project has three primary segments: 


e Satellite System - This includes both the Bus and 
payload systems. The payload systems specifically 
include the telescope, image detector, associated 
software, data management for the payload, and 
supporting systems. The Bus systems include 
communications system, flight computer and software, 
power generation and distribution, attitude 
determination and control systems, and structural 
systems, including thermal management. 
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e Mission Operations Systems —- This includes spacecraft 
control and flight test support Mission Operations 
Center (MMOC) and Ground Station. 

e Ground Support Systems —- This includes quality 
assurance, integrated testing and verification, and 
satellite handling. 

e Detailed information defining each of the segments and 
related subsystems is located in the Master Product 
Breakdown Structure. 


2.4 Schedule Baseline 

The program manager and the TINYSCOPE team will use 
this schedules for evaluating, managing, and reporting 
project performance with respect to baseline plans. Lower 
level schedules will be developed and monitored via major 
milestones and interim deliverables to be determined in 
those detailed development schedules. Variances will be 
addressed as program risks if threatening Major Milestone 
delivery dates. 


Major Milestone Date 


MRR Mission Requirements Review and 
Baseline G7 LS7 10 
_ Preliminary Design Review Rad 


Pp Flight Hardware Ship to Launch Site 


Operations Readiness Review 


2.5 Resource Baseline 


2 





2 6 
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Approval is restricted to above budget. Any deviation from 
the approved budget must get approval from both Primary 
Investigators. 


3 PROJECT CONTROL PLANS 


3.1 Technical, Schedule, and Cost Control Plan 

Phasing will conform generally to the proposal for 
research submitted to the AS&T, NRO for the period October 
lst, 2009 - December 31st, 2010. More specifically, the 
baseline schedule referenced in Section 2.5 of the Project 
Plan outlines the timeline of milestones and reviews. 
Reviews are held at the end of every phase as the control 
gate to end each phase as well as get approval to proceed 
to the next phase. The Systems Engineering Management Plan 
explicitly defines all deliverables for each milestone. The 
milestones will be used as a schedule performance metric 
with a recommended corrective action scheduled for each 
milestone past due. Lower level schedules will be developed 
and monitored via milestones and interim deliverables to be 
determined in detailed development schedules. Variances 
will be addressed as program risks if threatening milestone 
delivery dates. Cost performance metrics will consist of 
planned vs actual FY budget analysis performed monthly. 
Technical requirements will be reviewed monthly to ensure 
that each segment remains on track to meet performance 
objectives. 


3.2 Mission Assurance Plan 
TINYSCOPE reliability requirements support the 

characterization of the program as a short hardware life 
requirement, low complexity, low cost, short program 
duration, and economically replaceable. The TINYSCOPE 
hardware will be designed to operate for at least one 
complete mission cycle (minimum of 6 months) including 
ground operations prior to flight. The launch provider 
ground safety reviews will also be conducted to ensure 
compliance with their mission assurance requirements. 


3.3 Risk Management Plan 
The risk management strategy for the TINYSCOPE Project 
1s to identify, analyze, plan, track, control, communicate 
and document critical areas and risk events, both technical 
and non-technical, and take necessary action to manage them 
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to prevent serious cost, schedule or performance impacts. 
The program investigators and sponsors acknowledge and 
accept the high risk associated with a technology 
demonstration spacecraft. Risk information will be 
included in all program reviews and the project will be 
continuously monitored for areas that may add to project 
risk and associated mitigation methods. 


3.4 Acquisition Plan 
Standard Naval Postgraduate School procurement 
guidelines will be followed at all times. 


3.5 Systems Engineering Management Plan 

The Systems Engineering Management Plan explicitly 
defines the major milestones and defines all deliverables 
for each milestone. The SEMP is tailored to the TINYSCOPE 
project. The primary function of the SEMP is to provide the 
basis for implementing the technical effort and 
communicating what will be done, by whom, when, where, cost 
drivers, and why it is being done. The SEMP identifies the 
roles and responsibility interfaces of the technical effort 
and how those interfaces will be managed. The SEMP 
specifies the deliverables for each phase and milestone of 
the project so that control gates (major reviews) may be 
passed without slippage of schedule or technical progress. 
The SEMP also defines the quality assurance plan and 
methodology for the project. 


3.6 Software Management Plan 
The Software Management Plan defines the format of 
communications between the various subsystems . Where any 
disparities arise between the Software Management Plan and 
individual subsystem documentation, the SMP take 
Drececence. 


3.7 Review Plan 

The TINYSCOPE Project will conduct five major reviews 
prior to launch. Dates for the reviews will be maintained 
in the TINYSCOPE Master Schedule. The major reviews will 
consist of the following: 

MRR — Mission Requirements Review 

PDR —- Preliminary Design Review 

CDR. = Critical Desion, Review 


FRR — Flight Readiness Review 


ORR -— Operation Readiness Review 
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The purpose of the reviews are outlined in the Systems 
Engineering Management Plan (SEMP), but are generally used 
as control gates and evaluation of the progress of the 
flight hardware. Informal hardware development, science 
development and test readiness reviews will be conducted as 
necessary to evaluate interim development of the flight 
hardware. 


3.8 Mission Operations Plan 

The TINYSCOPE Mission Operations Plan applies to the 
prototype flight of the TINYSCOPE spacecraft and payload 
configuration. This plan provides the top level 
description of operations necessary to execute the mission. 
The plan will refer to specific documented procedures for 
detailed operations. This document outlines the sequence of 
events and operations to be conducted during the TINYSCOPE 
mission. 


3.9 Environmental Management Plan 
Environmental management of the spacecraft will be 
conducted in accordance with the Contamination Control 
Pelt. 


3.10 Logistics Plan 
The TINYSCOPE logistics strategy 1S captured in 
several documents including the SEMP and Mission Operations 
ele ch alae 


3.11 Data Management Plan 

TINYSCOPE documentation and mission data will be 
maintained by the Nanosat Advanced Concepts Lab for the 
duration of the spacecraft mission and for a minimum period 
of 3 years following completion of deorbit. Access to data 
by parties external to the United States Government will be 
handled IAW applicable regulations and subject to the 
approval of the director of the Space Systems Academic 
Group. Documentation for this project includes, but is not 
limited to, management plans, specifications, reports, 
technical publications, schematics, drawings, production 
and inspection records, test plans, procedures and reports. 


3.12 Security Plan 
The TINYSCOPE Project will ensure security and 
technology protection by complying with applicable Naval 
Postgraduate School policies and procedures. The TINYSCOPE 
Project does not have plans to transfer or ship any 
products outside of the U.S. All Mission Operations and 
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handling of hardware will occur at designated NASA or U.S. 
Air Force facilities. Wherever possible the TINYSCOPE 
project will utilize hardware that is not regulated under 
export control laws. However, as necessary the TINYSCOPE 
Project will adhere to the the Arms Export Control Act 
(Title 22, U.S.C., Sec 2751, et seq.) and the Export 
Administration Act of 1979, as amended (Title 50, U.S.C., 
App. 2401 et seq.) 
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1 INTRODUCTION 


1.1 Purpose 

This document delineates the design, CONST rUCE1 On, 
performance, and verification requirements LOr the 
EINYSCOPE PeO7eCE. This document additionally defines all 
tests, analyses, inspections and certification methods 
required for all applicable flight hardware. Acceptance 
tests will be conducted to ensure that critical performance 
parameters are likely to be achieved. tie TINYSCOPE 
project 1S primarily used as a vehicle for student research 
and hands on experience with design, construction and 
integration of satellite hardware. Due to the project’s 
Size, scope, cost and schedule, the risk constraints for 
the project are somewhat relaxed when compared to 
traditional space flight. As such qualification testing is 
required only for verification of safety compliance and 
interface compatibility with the launch vehicle adapter. 
This document will serve as both a planning guide and a 
checklist for verifying that all conditions are met to 
include design Cert iT 1Cation, acceptance testing and 
qualification testing. 


1.2 Scope 
This document provides the baseline requirements for 
the TINYSCOPE spacecraft. The document is published to 
provide necessary guidance to engineering for development 
of system design solutions. No specific design solution is 
specified by this document. 


1.3 Definitions 
The following definitions differentiate between 
requirements and other statements. 


Shall: This is the only verb used for the binding 
requirements. 
Should/May: These verbs are used for stating non- 


mandatory goals. 


Will: This verb 1s used for stating factS or 
declaration of purpose. 


1.4 Responsibility and Change Authority 
The responsibility for the development or ths 
document lies with the TINYSCOPE Project Team at the Naval 
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Postgraduate School. Derived requirements will be added to 
this document following a quarterly review process by the 
Student Program Manager and Systems Engineer until the 
Critical Design Review. Following CDR, the change 
authority will be the Student Program Manager with 
concurrence of both Principal Investigators. 


2 APPLICABLE AND REFERENCE DOCUMENTS 


2.1 Reference Documents 
The following documents are reference documents 
utilized in the development of this specification. These 
documents do TOE TOrM a@ Dart Of Lhis Speci ticavion, and are 
not controlled by their reference herein. 


2.2 Order of Precedence 

All specifications, standards, exhibits, drawings or 
other documents that are invoked as “applicable” in this 
requirements document are incorporated as cited. All 
documents that are referred to within an applicable 
document are considered to be for guidance and information 
only, with the exception of Interface Control Documents 
that shall have their applicable documents considered to be 
incorporated as cited. 


2.3 Application and Traceability 
These requirements will drive the derivation of 
functional, physical, and performance specifications for 
the TINYSCOPE project. The verification of these 
requirements shall certify this hardware for flight. These 
requirements shall be tracéeble to the functions and 
physical configuration items that meet the requirements. 


3 KEY PERFORMANCE PARAMETERS 

The TINYSCOPE Project has a number of Key Performance 
Parameters (KPPs) that are considered critical or essential 
to the demonstration of an effective capability. Each KPP 
has a threshold, representing the required value, and an 
objective, representing the desired value. 


3.1 Mission Duration (KPP 1) 

The satellite shall be operational for a period of six 
months following commissioning (threshold) and should be 
designed LOL operations of one year (objective). 
Operational is defined as having the capability to receive 
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commands, point to and collect images of given targets, and 
transmit collected data to the ground station. 


3.2 Earth Imaging Resolution (KPP 2) 

The satellite shall provide panchromatic images of the 
earth in the visible spectrum with an effective ground 
sampling distance of 5.0m (threshold) at nadir and should 
be designed to achieve a ground sampling distance of 3.1m 
(objective). 


3.3 Telescope Field of View (KPP 3) 

The satellite shall have a swath area of 25 square 
kilometers (threshold) at nadir and should be designed to 
achieve a swath area of 50 square kilometers at nadir 
(objective). 


3.4 Image Collection Capacity (KPP 4) 

The satellite shall be capable of collecting and 
transmitting LO an accessible ground Stall on, two 
diametrically opposed off-nadir images (threshold) in a ten 
degree along track band. The satellite should be capable 
of collecting and transmitting four diametrically opposed 
off-nadir images (objective) in a ten degree along track 
band. 


3.5 Geo-location Accuracy (KPP 5) 
The satellite shall have a circular ground targeting 
error of less than 200m (threshold) and should be designed 
to reduce error to less than 100m (objective). 


4 MISSION HARDWARE REQUIREMENTS 
4.1 Description 


4.1.1 Payload 
The TINYSCOPE payload will be composed of the telescope, 
camera module, all associated control electronics, all 
associated mounting, focusing, and alignment hardware, and 
required software to meet payload performance requirements. 


4.1.2 Spacecraft 
The TINYSCOPE spacecraft provides power to the focal plane 
array, attitude and thermal control, command and data 
handling and communications. 


4.1.3 Communications Ground Station 
The TINYSCOPE ground station will provide an intermittent 
link between the satellite and the flight operations 
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element. The ground station consists of a steerable 
antenna, a telemetry tracking receiver, high and low 
frequency synthesizers and computer hardware with orbit 
propagation software. 


4.1.4 Mission Operations Center 
The Mission Operations Center consists of three operational 
elements: flight operations, activity planning and data 
management. The flight operations element communicates 
with and controls the satellite through the ground station. 
Activity planning and data management interact with the end 
user of the TINYSCOPE product. Figure 11 shows how each 
element interacts with others. 


4.2 TINYSCOPE Satellite Assembly 
This section of this document describes all 
functional, performance, physical, and technical 
attributes, characteristics, requirements and constraints 
that are applicable to the spacecraft. 


4.2.1 Functional Requirements 
TINYSCOPE Payload Subsystem 


TR-1 The payload shall allow on-board imagery 
processing and compression operations to be 
selectively disabled. 


TR-2 The payload shall meet or exceed imagery 
requirements at all points in orbit and in 
orientations up to 30 degrees off-nadir to either 
side of the orbital plane. 


TR-3 The payload shall remain fully functional at all 
points in orbit and in orientations up to 30 degrees 
off-nadir to either side of the orbital plane. 


TR-4 The payload shall have instrument OFF, SAFE and 
OPERATIONAL modes. 


TR-5 The payload shall continue to collect and 
transmit telemetry data to the spacecraft when in 
SAFE mode. 


TR-6 The payload shall be commanded by the 
spacecraft. 


TR-7 The payload shall autonomously enter SAFE mode 
in the event of direct solar illumination. 
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TR-8 The payload shall be in OFF mode during launch. 
TINYSCOPE Bus Subsystem 


TR-9 The spacecraft shall autonomously activate 
following deployment from the launch vehicle. 


TR-10 The spacecraft shall autonomously maneuver to a 
stable attitude following deployment from the launch 
vehicle. 


TR-11 The spacecraft shall autonomously acquire the 
sun after deployment from the launch vehicle. 


TR-12 The spacecraft shall autonomously enter an 
attitude that maximizes sun exposure after attitude 
SUebidlaZec1 or: 


TR-13 The spacecraft shall be capable of being 
commanded into any operational mode from the ground. 


TR-14 The spacecraft shall autonomously transition to 
SAFE mode upon detection of any fault that threatens 
the health and safety of the spacecrart. 


TR=LO The Spacecraere shall, Pransiver1on OUl Of SAFE 
mode only after command from the ground. 


TR-16 Spacecraft autonomous functions shall be 
performed using on-board software. 


TR-17 The spacecraft shall be capable of initiating a 
stored response to pre-defined telemetry conditions. 


TR-18 The spacecraft shall record all autonomous 
operations to the telemetry log. 


TR-19 The spacecraft shall report detection of out of 
limit conditions for monitored systems in the 
telemetry log. 


TR-20 The spacecraft shall command the payload to 
SAFE mode when the sun is predicted to enter the 
field of view. 


FRlectrical Power Subsystem (EPS) 
TR-21 The EPS shall provide a single point ground 


within the power subsystem. 
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TR-22 The EPS shall provide power generation, power 
control, energy storage and distribution to the 
spacecraft. 


TR-23 The EPS shall provide conditioned electrical 
power for all Spacecraft operational modes during 
eclipse Conditions. 


TR-24 The EPS shall provide battery management and 
hoed shedding Contre. . 


TR-25 The EPS shall distribute direct current power 
to the loads at either 3.3 or 5 Volts. 


TR-26 The spacecraft shall return to a full state of 
charge condition in the battery at least once in 
five orbits. 


TR-27 The spacecraft shall be capable of autonomously 
assuming a maximum sun exposure orientation upon 
detection of a low battery charge state. 


TR-28 The spacecraft shall be in an orientation that 
maximizes exposure of the solar array to the sun 
while in SAFE mode. 


TR-29 The EPS shall provide short circuit protection 
or current limitation for each switchable power 
CIeeCuLt.. 


TR-30 The EPS shall provide protection from over 
voltage and under voltage conditions. 


TR-31 The spacecraft shall be capable of being 
powered from an external source while on the ground 
with or without batteries installed. 


TR-32 The EPS shall at a minimum monitor and report 
in telemetry logs the switch positions, current, and 
voltage levels for each circuit at the power 

Gist riDul won. DoOunc., 


TR-33 The spacecraft battery capacity shall be 1.25 
times the nominal charge / discharge profile at the 
end of the spacecraft design life. 


TR-34 The EPS shall be capable of electrically 
bypassing failed battery cells. 


Attitude Control and Determination Subsystem 
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TR-35 The Spacecraft shall remain thermally stable, 
under stable attitude control, and operationally 
functional within its design requirements up to 30 
degrees off-nadir on either side of the orbit plane. 


TR-36 The Spacecraft shall use the UTC time as the 
spacecraft time reference. 


TR-37 The Spacecraft shall be capable of receiving a 
ground base Spacecraft reference time and time 
correction coefficients. 


TR-38 The Spacecraft shall generate an on-board 
ephemeris based on the Global Positioning System 
(GPS) ena On=board Star Lracker. 


TR-39 The Spacecraft shall include the GPS carrier 
phase and pseudo range values in the spacecraft 
ancillary data stream. 


TR-40 The Spacecraft shall be capable of receiving a 
ground based ephemeris update. 


TR-41 The Spacecraft shall report the orbital 
position and velocity once per second in the 
spacecraft telemetry log. 


Communications Subsystem 


TR-42 The Communications Subsystem shall provide two- 
way RF communications for uplink of command and 
control data and downlink of payload data and 
satellite health and status data. 


TR-43 The Communications Subsystem shall comply with 
National Telecommunications and Information 
Administration (NTIA) Spectrum Standards. 


TR-44 The Communications Subsystem shall comply with 
International Telecommunication Union (ITU) spectrum 
utilization and sharing requirements. 


TR-45 The Communications Subsystem shall be capable 
of reception of ground commands while in any 
operational mode. 


TR-46 The Communications Subsystem shall be capable 
of transmissions in any operational mode. 
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TR-47 The Communications Subsystem shall be capable 
OF CransSmLssions in any Oorlentatwon.. 


TR-48 The primary communications system shall be 
powered at all times except when the satellite 1s in 
EMERGENCY Mode. 


TR-49 The primary communications system shall be 
capable of being enabled and disabled via ground 
command. 


TR-50 The primary communications system shall be S- 
band. 


TR-51 The command uplink shall be encrypted. 


TR-52 The beacon system shall provide broadcasts in 
compliance with FCC Amateur Radio Regulations (Part 
D1) 


TR-53 The beacon system shall be powered from 
activation through the life of the mission. 


TR-54 The beacon system shall be capable of being 
enabled and disabled via ground command. 


TR-55 The beacon system shall be capable of receiving 
commands in all spacecraft operational modes. 


TR-56 The beacon system shall be automatically 
disabled after 21 days in the event that no 
satellite commands are received. 


TR-57 The beacon system shall be designed such that 
its broadcasts can be reliably received with a 
typical OSCAR-class amateur radio communication 
StacioOn, 


TR-58 The beacon system shall utilize AX.25 encoding 
Prorocol using 1700 baud, 1 Starv bac, 36 dave bics, 
and 1 stop bit format. 


TR-59 The beacon system shall broadcast data messages 
of up to 64 characters of telemetry and messages 
from the bus for transmission within the beacon 
broadcasts, which shall contain the “TINYSCOPE” 
character string in its packet. 


Command and Data Handling Subsystem 
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TR-60 The Spacecraft shall be capable of monitoring 
the health and safety of the spacecraft and payload. 


TR-61 The Spacecraft shall report in spacecraft 
telemetry log the health and safety of the 
spacecraft and payload. 


TR-62 The Spacecraft onboard processor shall be 
capable of being reset via a ground command. 


TR-63 The Spacecraft shall convert analog sensor data 
CO Gdrgital Tormac . 


TR-64 The Spacecraft shall transmit real-time 
telemetry data to the ground when in contact with a 
ground station. 


TR-65 The Spacecraft shall record all telemetry data. 


TR-66 The Spacecraft shall be capable of concurrent 
transmission and storage of real-time telemetry. 


TR-67 The Spacecraft shall report command acceptance 
or rejection in telemetry log upon receipt. 


TR-68 The Spacecraft shall report command execution 
in telemetry log. 


TR-69 The Spacecraft shall be capable of playing back 
stored telemetry data while in any mode. 


TR-70 The Spacecraft shall be capable of decrypting 
command and data uploads using civil decryption 
Coding. 


TR-/71l The Spacecraft shall be capable of source 
authentication of all received commands. 


TR-72 The Spacecraft shall execute only commands that 
are source authenticated. 


TR-73 The Spacecraft shall have a command 
authentication bypass. 


TR-74 The Spacecraft command authentication bypass 
shall be accomplished by means of a fixed length 
timer. 
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TR-75 The Spacecraft shall autonomously reset the 
authentication bypass timer upon receipt of a 
successfully authenticated command. 


TR-76 The Spacecraft shall reject invalid commands. 


TR-77 The Spacecraft shall identify rejected commands 
in telemetry log(s). 


TR-78 The Spacecraft shall validate, process, and 
execute flight software update commands, ephemeris 
table data, and star database loads. 


TR-79 The Spacecraft shall be capable of receiving 
command loads across multiple contacts. 


TR-80 The Spacecraft shall be capable of receiving 
flight software updates across multiple contacts. 


TR-81 The Spacecraft shall use unique commands to 
change state and condition. 


TR-82 The Spacecraft shall record all mission data. 


TR-83 The Spacecraft shall be capable of resending 
stored mission data multiple times. 


TR-84 The Spacecraft shall retain all stored data 
when transitioning into and out of any operational 
mode. 


TR-85 The Spacecraft shall acquire ephemeris and 
ancillary data from the spacecraft that is necessary 
to meet instrument imaging requirements. 


TR-86 The Spacecraft shall use a file based data 
management. scheme Lor stored data. 


TR-87 The Spacecraft shall provide a listing or 
directory of its file system including file 
attributes on command. 


TR-88 The Spacecraft shall maintain mass storage file 
attributes that include at a minimum: 


e A file name 
e A unique time stamp 
e The file length 
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e Flags that provide data protection status (over- 
write or not) 


e Flag that indicates whether the file has been 
transmitted 


TR-89 The Spacecraft shall uniquely identify each 
data file in mass storage uSing a root name 
associated with the ground location of the data 
CONntenC 


TR-90 The Spacecraft shall designate any single or 
set of mission data files as protected on command. 


TR-91 The Spacecraft shall autonomously mark mission 
data files in mass storage as non-protected after 
acknowledgement of receipt by the ground station. 


TR-92 The Spacecraft shall designate any single or 
set of mission data files as non-protected on 
command. 


TR-93 The Spacecraft shall only overwrite non- 
protected mission data. 


TR-94 The Spacecraft shall overwrite mission data 
starting from oldest to youngest. 


TR-95 The Spacecraft shall be capable of repeat 
playbacks of stored data. 


TR-96 The Spacecraft shall autonomously determine 
which mass storage files will be down- linked at the 
next ground contact opportunity. 


TR-97 The Spacecraft shall downlink mass storage 
files in a non-standard order upon command from the 
Ground. 


TR-98 The Spacecraft shall retransmit individual 
files on command. 


TR-99 The Spacecraft shall be capable of diagnosing 
mass storage problems. 


TR-100 The Spacecraft shall have autonomous internal 
fault detection and responses for each subsystem. 


TR-101 The Spacecraft shall record in telemetry log 
that. faults responses have been completed. 
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Thermal Control 


TR-102 The Spacecraft shall be thermally safe for 
continuous operations in all operational modes. 


TR-103 The Spacecraft shall have a thermal control 
system that monitors and reports in the telemetry 
log the temperatures of subsystems on the 
spacecraft. 


Structural and Mechanical 


TR-104 The Spacecraft structure shall provide a 
structural mounting interface with a nadir field-of- 
view clear of obstructions for the payload. 


TR-105 The Spacecraft structure shall include a 
structural mounting interface that is isolated from 
mechanical and thermal disturbances from the 
spacecraft 


TR-106 The Spacecraft shall be designed to permit 
full range deployment of mechanisms after 
integration with the Spacecraft during ground 
processing. 


Flight Software 


TR-107 The Spacecraft flight software shall be 
reprogrammable on orbit. 


TR-108 The Spacecraft shall monitor software tasks to 
detect for infinite loops or stalled processes. 


TR-109 The Spacecraft flight software shall detect 
and correct single bit memory errors. 


TR-110 The Spacecraft stored commands shall be 
unaffected by a flight software upload. 


TR-1l11 The Spacecraft flight software shall store the 
version identifier of reprogrammable software 
onboard. 


TR-112 The Spacecraft shall preserve contents of the 
telemetry log after rebooting or power cycling. 


TR-113 The Spacecraft shall initialize flight 
software and begin operations without the need of a 
ground based command. 
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TR-114 The Spacecraft processor shall execute a 
restart of its software in response to a ground 
command. 


TR-115 The Spacecraft flight software shall provide a 
capability to store and execute absolute-time 
command sequences. 


TR-116 The Spacecraft flight software shall provide a 
capability to store and execute relative-time 
command sequences. 


TR-117 The Spacecraft flight software shall execute 
real-time commands before executing stored commands. 


TR-118 The Spacecraft flight software shall provide 
the capability to store multiple time-tagged command 
sequences. 


TR-119 The Spacecraft flight software stored command 
sequences shall be modifiable by ground command. 


TR-120 The Spacecraft flight software command 
sequences shall be enabled, disabled or canceled by 
ground command. 


TR-121 The Spacecraft flight software shall be 
capable of placing the contents of the stored 
command buffer into the telemetry log. 


TR-122 The Spacecraft flight software shall uniquely 
identify stored command sequences. 


TR-123 The Spacecraft flight software shall use the 
unique command sequence identifier to report the 
status of each actively executing command sequence 
in telemetry. 


4.1.2 Performance Requirements 
4.2.1.1 TINYSCOPE Payload Subsystem 


TR-124 The payload shall have a minimum field of view 
that provides a 25 square kilometer swath when nadir 
polncLing. 


TR-125 Data compression algorithms applied to image 
data shall be lossless. 
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TR=LZ6 NON=UntrOrmity Correction algorithms shat be 
fully reversible and coefficients shall be 
transmitted with each image file. 


TR-127 The payload shall provide a pixel-to-pixel 
increment, in both the along track and cross track 
directions, equivalent to a Ground Sampling Distance 
(GSD) less than or equal to 4 meters for a 
panchromatic band. 


TR-128 Payload data shall be quantized to a minimum 
Or @ Dis. 


TR-129 The payload structure shall be of sufficient 
strength and stiffness to maintain structural 
integrity during ground testing and transportation 
and launch. 


TR-130 The payload structure shall provide a mounting 
interface to the spacecraft bus. 


TR-131 The payload structure shall include a 
mechanical alignment device to co-align the optical 
path to the spacecraft bus structure and inertial 
reference frame. 


TR-132 The payload mechanical alignment device shall 
be internally stable through the full range of 
design temperatures. 


TR-133 The payload shall be thermally stable while in 
operational modes. 


TR-134 The payload shall be designed to operate from 
a 5V direct current power subsystem. 


TR-135 The payload shall have an average power 
consumption that does not exceed 8 Watts. 


TR-136 The payload shall have a peak power 
consumption that does not exceed 10 Watts. 


TR-137 The payload software shall be reprogrammable 
On: Orb iC. 


TR-138 The payload processor shall be capable of 
being reset on orbit. 


TR-loo ine pevyloed processor Shall contanuously 
monitor its health and safety. 
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TR-140 The payload shall time tag image data with 
accuracy of 1 millisecond relative to the spacecraft 
time reference. 


TR-141 The payload software shall provide sufficient 
telemetry to ensure proper control and monitoring of 
health and safety and to identify anomalous 
conditions. 


TR-142 The payload shall be designed to operate and 
meet all design requirements for six months 
FOLLOWING -cOoMmmisslonaing on Orbit. 


TR-143 The payload shall be capable of being placed 
in a state of storage without requiring maintenance 
for a period of six months. 


4.2.1.2 TINYSCOPE Bus Subsystem 


TR-144 The spacecraft shall be capable of operating 
safely without any ground intervention for a period 
Or: 7Z Nours. 


Electrical Power Subsystem 


TR-145 The spacecraft shall provide continuous and 
peak power with a 20% margin for all phases of 
mission operation. 


Attitude Control and Determination Subsystem 


TR-146 The Spacecraft shall perform maneuvers to any 
inertial attitude meeting pointing requirements and 
Stabilize within 90 seconds. 


TR-147 The spacecraft shall have absolute pointing 
accuracy of less than or equal to Q.1 degrees. 


TR-148 The Spacecraft shall compute orbital position 
accurate to 30 m radial, 30 m in-track, and 30 m 
CLrOSS—-Lrack. 


TR-149 The Spacecraft shall provide orbital velocity 
accurate to 0.30 m/sec radial, 0.30 m/sec in-track, 
and 0.30 M/Ssee Cross: track. 


TR-150 The Spacecraft shall be capable of propagating 
the on-board state for at least 24 hours. 
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TReLol The spacecrart shall Support ameqing 
operations for up to 24-hours from an onboard 
propagated ephemeris. 


Communications Subsystem 


TR-152 Radio frequency link margins shall be at least 
+3dB in all operational modes. 


TR-153 The spacecraft shall transmit a minimum of 90% 
of real-time and recorded telemetry to the ground 
segment. 


TR-154 The primary communications system shall have a 
bit error rate (BER) at operational data rates of 
less than or equal to 1E-6 after demodulation and 
error correction. 


TR-155 The primary command uplink shall be at 16 
Kbps « 


TR-156 The primary downlink shall at a minimum be 1.2 
MDDS 


TR-157 The backup command uplink shall be ata 
minimum 250 bps to the beacon system. 


TR-158 The backup downlink through the beacon system 
shall be at a minimum 200 bps. 


TR-159 The beacon system shall have minimum broadcast 
repetition rates on the order of 5-60 seconds. 


TR-160 The beacon system shall have a bit error rate 
(BER) at operational data rates of less than or 
equal to 1E-5 after demodulation and error 
correction. 


Command and Data Handling Subsystem 


TR-161 The Spacecraft shall be capable of storing at 
least 72 hours of Spacecraft telemetry data at the 
maximum onboard telemetry rate. 


TR-162 The Spacecraft shall be capable of storing at 
least 72 uncompressed images and associated 
ephemeris and ancillary data. 
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TR-163 The Spacecraft shall time tag ephemeris and 
ancillary data to the spacecraft time reference with 
am: accuracy ofr 1. mid ilasecond. 


TR-164 The Spacecraft shall time-tag telemetry data 
to the spacecraft time reference with an accuracy of 
1 millisecond. 


Structural and Mechanical 


TR-165 The Spacecraft structure shall be sufficiently 
stiff to meet the axial and lateral frequency 
requirements as defined in GSFC-STD-7/000. 


TR-166 The Spacecraft structure shall be of 
sufficient strength and stiffness to maintain 
structural integrity and withstand all launch and 
launch vehicle separation environments as defined in 
GokC=5SfD=-7000.. 


TR-167 The Spacecraft structure shall be of 
sufficient strength and stiffness to maintain 
Structural ancegricy and withstand all ground 
testing, Handling, transportarcion, and Mission on- 
orbit environments as defined in GSFC-STD-7000. 


Flight Software 


TR-168 The Spacecraft flight software stored command 
capability shall store up to 72 hours of spacecraft 
Command. Sequences. 


TR-169 The Spacecraft flight software shall be 
capable of executing commands with an accuracy of 
100 milliseconds or less. 


4.1.2 Physical Characteristics 
TR-170 The TINYSCOPE system mass shall consist of the 
TINYSCOPE satellite bus and the payload subsystem 
with a launch mass of 14 kg or less. 


TR=L7 1 TINYSCOPE. shall contorm to: ali. applicable 
standards for the Nanosatellite Launch Adapter 
DV Cee. 


4.1.3 Environmental Requirements 
TR-172 All subsystems shall be qualified at 
acceptance levels for Thermal Cycle, Thermal Vacuum 
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Cycle, Vibration, and Shock Testing as defined in 
GSEC=SID=7000:. 


TR-173 The satellite bus and payload electronics 
shall be capable of correcting for single event 
memory corruption caused by radiation. 


TR-174 The TINYSCOPE spacecraft and payload shall be 
capable of operation in low Earth orbit (LEO) 
without unrecoverable failure due to radiation 
effects. 


4.3 Communications Ground Station (GS) 


4.3.1 Functional Performance 
TR-175 The GS shall provide the capability to measure 
beacon signal strength. 


TR-176 The GS shall provide the capability to 
autonomously steer the antenna in azimuth and 
elevation to track the beacon signal. 


TR-177 The GS shall provide the capability to 
manually steer the antenna in azimuth and elevation 
to track the beacon signal. 


TR-178 The GS shall have the capability to receive 
transmissions from the satellite primary 
communications system. 


TR-179 The GS shall have the capability to encode and 
decode beacon and primary signals. 


TR-180 The GS shall have the capability to receive 
commands and scripts from the MOC. 


TR-181 The GS shall have the capability to transfer 
data CoO the MOC. 


TR-182 The GS shall have the ability to be controlled 
from the MOC. 


TR-183 The GS shall have the capability to encrypt 
and decrypt communications. 


TR-184 The GS shall have the capability to propagate 
satellite orbits. 


TR-185 The GS antenna shall have the capability to 
Seal. 
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TR-186 The GS shall have the capability to transmit 
and receive simultaneously. 


4.4 Mission Operations Center (MOC) 


4.4.1 General 
TR-187 The MOC shall use Universal Time Coordinated 
(UTC) time as the time base for all operations 
activities. 


TR-188 The MOC shall receive all data for the life of 
Lhe mission. 


TR-189 The MOC shall support end of life 
decommissioning activities. 


TR-190 The MOC shall support a single 8-hour by 5-day 
shift (M-F) approach and operate autonomously 
whenever not staffed. 


TR-LOLALIL Euncttonak applications am the MOC shall 
have the ability to run unattended while performing 
ald, POUTING and, pPErl1OdiCc operaclcions for 7Z hours: 


TR-192 The MOC shall autonomously monitor the event 
log and notify appropriate on-call personnel when 
the MOC is not staffed. 


TR-193 The MOC shall generate commands for 
transmission to the spacecraft. 


TR-194 The MOC shall accept telemetry and mission 
data from the spacecraft. 


TR-195 The MOC shall send spacecraft commands to the 
Ground Station tor S=band uplink. 


TR-196 The MOC shall receive real-time telemetry from 
the ground station. 


TR-197 The MOC shall receive stored telemetry logs 
from the ground station. 


4.4.2 Activity Planning Element (APE) 
TR-198 The APE shall provide the capability to plan 
and schedule all spacecraft collection and 
maintenance activities for the life of the mission. 
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TR-199 The APE shall produce time-ordered activity 
plans listing all planned activities for the 
spacecraft planning window. 


TR-200 The APE shall incorporate all resource down 
times or reserved times into schedule generation 
events. 


TR-201 The APE shall convert collection and 
maintenance requests into spacecraft activities. 


TR-202 The APE shall provide the capability to create 
and. MOdLEY eaCTIVILY DYrTOTIC1es, Constraints, atid 
rules. 


TR-203 The APE shall automatically check for activity 
constraint and rule violations during schedule 
generation. 


TR-204 The APE shall automatically check for resource 
constraint and rule violations during schedule 
generation. 


TR-205 The APE shall provide the capability to 
automatically schedule all spacecraft and ground 
Station activities within operational resource 
COMSCrainles . 


TR-206 The APE shall provide the capability to 
produce a Coordinated Universal Time (UTC) time- 
based activity schedule in terms of specific 
start/stop times. 


TR-207 The APE shall provide the capability to 
Generacre a conurliace-Tfree eacuivity schedule spanning 
12-HOUrSs OF GCC. 


TR-208 The APE shall provide the capability to 
generate a graphical timeline of activity plans and 
Senedules.« 


TR-209 The APE shall provide a display of planned, 
currently active and past observatory and ground 
activities. 


TR-210 The APE shall produce and deliver activity 
schedules to the data management element. 
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TR-211 The APE shall be capable of archiving and 
recovering all planning and scheduling data for the 
life of the mission. 


4.4.3 Flight Operations Element (FOE) 
TR-212 The FOE shall interface with the ground 
communications network for the exchange of mission 
data and products among the ground system elements. 


TR-213 The FOE shall provide an interface between the 
ground system elements and the space-ground 
communications links. 


TR-214 The FOE shall provide an anomaly reporting and 
Stecus TreckingG Capebiulacy.. 


TR-215 The FOE shall ensure that no single point of 
failure eGxists Lor Critical command and control 
LUNCE ONS. 


TR-216 The FOE shall provide the capability to 
Support training, testing, or system maintenance 
WiC DO DNeCerrupeion To FOE, funcelonaliacy. 


TR-217 The FOE shall provide the capability to log, 
track, and report system faults and failures. 


TR-218 The FOE shall be capable of generating 
commands to perform the spacecraft functions. 


TR-219 The FOE shall be capable of generating 
commands to support the retransmission of telemetry 
data. 


TR-220 The FOE shall perform command encryption and 
authentication. 


The FOE shall assign levels of command authority to 
ensure that only authorized personnel can perform 
designated command functions. 


TR=-Z221 ‘Command authority shall be controlled by boogin 
attributes. 


TR-222 The FOE shall provide the capability to allow 
authorized operators to transmit commands to the 
observatory. 
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TR-223 The FOE shall prevent simultaneous sending of 
commands by multiple operators. 


TR-224 The FOE shall provide the capability to 
perform real time commanding to the observatory. 


TR-225 The FOE shall perform verification of real- 
time commands to the observatory. 


TR-226 The FOE shall provide the capability to 
generate, uplink, and verify discrete observatory 
commands. 


TR-227 The FOE shall provide the capability to 
generate command sequences via a scripting language. 


TR-228 The FOE shall provide the capability to uplink 
command scripts or software updates that are stored 
as named files. 


TR-229 The FOE shall produce a load generation report 
for ~alt bkoads, Conlaiming accounting 1ntormacion, 
description of load contents, any warning and/or 
error messages and a summary of creation results. 


TR-230 The FOE shall be capable of performing 
automatic constraint and rule checking of discrete 
commands and command loads. 


TR-231 The FOE shall require at least one additional 
Operaclor COnrTArmatton prior to Che Cransmission O71 
commands or command sequences that have failed 
constraint check. 


TR-232 The FOE shall be capable of notifying the 
Operalor Lhat. the commands sent Co Lhe spacecraLlt 
were correctly received. 


TR-233 The FOE shall provide the capability to 
manually retransmit commands or command loads that 
were not accepted by the spacecraft. 


TR-234 The FOE shall define spacecraft commands and 
their characteristics in a command database. 


TR-235 The FOK shall have the capability to search 
and sort spacecraft commands defined in the command 
database. 
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TR-236 The FOE shall archive all command operations 
and command history for the life of the mission. 


TR-237 The FOE shall provide the capability to time 
tag all spacecraft and ground system data with a UTC 
time. 


TR-238 The FOE shall provide the capability to replay 
telemetry by ground receipt time or spacecraft time. 


TR-239 The FOE shall provide the capability to 
display operator-selected telemetry data in real 
time. 


TR-240 The FOE shall provide a capability to verify 
in real-time that telemetry parameters are within 
prescribed operating limits. 


TR-241 The FOE shall define spacecraft telemetry and 
their characteristics ina telemetry database. 


TR-242 The FOK shall have the capability to search 
and sort spacecraft telemetry defined in the 
telemetry database. 


FR—243 The FOE shall be capable of ingesting and 
storing all telemetry data for trending and 
analysis. 


TR-244 The FOE shall examine spacecraft data to 
determine if any unexpected deviations from the pre- 
planned timeline have occurred. 


TR-245 The FOE shall produce an as-flown timeline 
that reflects the activities that were actually 
executed by the spacecraft. 


TR-246 The FOE shall create pass summaries that 
describe the results of each spacecraft contact. 


TR-247 The FOE shall perform evaluation of on-board 
derived ephemeris and attitude estimates available 
in the telemetry log. 


TR-248 The FOE shall provide the capability to 
automatically detect when the spacecraft orbital 
parameters deviate from established limits. 
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TR-249 The FOE shall have the capability to perform 
real-time attitude estimation using raw sensor data 
in the telemetry data. 


TR-250 The FOK shall provide the capability to 
generate the definitive ephemeris of the observatory 
at an accuracy of 30m in each axis. 


TR-251 The FOE shall provide the capability to 
propagate the observatory orbit for 72 hours. 


TR-252 The FOE shall produce data necessary to 
support Conjunction Assessment activities. 


TR-253 The FOE shall receive data necessary to 
support Conjunction Assessment activities. 


TR-254 The FOE shall propagate object ephemeris and 
compare results to predicted observatory ephemeris. 


TR-255 The FOE shall have the capability to generate 
attitude estimates of accuracy meeting mission 
requirements from raw sensor data contained in 
telemetry logs. 


TR-256 The FOE shall be capable of validating the on- 
board attitude estimates meet mission accuracy 
requirements. 


TR-257 The FOE shall predict star tracker target 
fields and compare these predicts to star 
acquisition data available in telemetry logs on an 
as-needed basis. 


TR-258 The FOE shall accept a star catalog from an 
external source and have the ability to maintain and 
uplink the star catalog. 


TR-259 The FOE shall be capable of generating 
maneuver plans in support of all observatory 
attitude maintenance and collection activities. 


TR-260 The FOE shall monitor on-board sensor 
calibrations and re-calibrate, as necessary to meet 
absolute attitude accuracy requirements. 


TR-261 The FOE shall specify and generate attitude 
sensor calibration maneuver sequences to provide 
sufficient sensor data to derive sensor alignment & 
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calibration coefficients meeting mission attitude 
determination requirements. 


TR-262 The FOE shall provide a capability to display 
the spacecraft orbit and ground tracks. 


TR-263 The FOE shall be capable of ingesting 
externally-generated spacecraft ephemeris data. 


TR-264 The FOE shall provide the capability to modify 
any re-programmable/writeable memory locations on 
the observatory. 


TR-265 The FOE shall have the capability to command 
data in mass storage to be unprotected. 


TR-266 The FOE shall provide a capability for 
operators to select data in mass storage for 
downlink. 


TR-267 The FOE shall time tag all event messages with 
a UTC time. 


TR-268 The FOE shall provide the capability to log 
all event messages for the life of the mission. 


TR-269 The FOE shall provide the capability to 
display any event messages and logs. 


TR-270 The FOE shall be capable of autonomously 
establishing a command and telemetry link with the 
ground station for every spacecraft contact. 


4.4.4 Data Management Element (DME) 
TR-271 The DME shall provide the capability to 
archive and retrieve engineering data products. 


TR-272 The DME shall provide the capability to 
archive and retrieve telemetry data products. 


TR-273 The DME shall provide the capability to 
archive and retrieve mission data products. 


TR-274 The DME shall archive all mission data in raw 
ana processeo: forms. 


TR-275 The DME shall archive raw mission data ina 
separate archive from processed data. 
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TR-276 The DME shall provide the capability to 
authorize and limit access to archival databases. 


TR-277 The DME shall provide the capability to 
distribute raw and processed mission data to users. 


TR-278 The DME shall provide the capability to 
provide, at a minimum, the following basic services: 


e Image georeferencing 
® Orvchborec lit 1cat1on 


e Correct radiometric distortion caused by 
instrumentation error 


5 MISSION OPERATIONS REQUIREMENTS 
TR-279 The spacecraft shall be powered off following 
integration and throughout launch operations. 


TR-280 The TINYSCOPE satellite mission operations 
shall begin no later than 24 hours prior to launch. 


TR-281 The TINYSCOPE System shall be capable of 
operations from the NPS Mission Operations Center. 


TR-282 The spacecraft shall be designed to operate 
and meet all design requirements for six months 
LOllLOWwWInNG Commissioning -on. orbit. 


TR-283 The spacecraft shall be capable of being 
placed ina state of storage without requiring 
maintenance for a period of six months. 


TR-284 The spacecraft shall be designed for an 
overall probability of success of 80% at the end of 
its design life. 


TR-285 The spacecraft shall be compliant with NASA 
requirements for limiting orbital debris. 


TR-286 The spacecraft shall be designed to operate in 
a sun-synchronous circular orbit at an altitude of 
500 kilometers +- 120 kilometers. 


TR-287 The spacecraft shall have three operational 
modes as follows: 


e NORMAL Mode is the nominal operational mode for 
thie Spacecrarel. 


116 


Project TINYSCOPE 


NACL10- 





Certification and Requirements Document 02-7 


e SAFE Mode provides maximum sun exposure to the 
solar array and a spacecraft configuration that 
does not allow image collection. The payload and 
S-band radio are deactivated and the beacon 
system transmits continuous telemetry data 
through the omni-directional antenna. 

e EMERGENCY Mode deactivates all subsystems with 
the exception of the beacon system. The beacon 
transmits a periodic distress signal along with 
telemetry data to preserve power. The EPS 
provides a direct path from the solar array to 
the battery for charging. The spacecraft is not 
capable of image collection, high rate 
communication, or attitude control in EMERGENCY 
Mode. 


6 VERIFICATION REQUIREMENTS 


6.1 Structural and Mechanical Verification Requirements 
TR-288 Random vibration tests shall be conducted on 
the integrated spacecraft bus, payload system, and 
the final spacecraft assembly. 


TR-289 Random vibration tests shall cover frequency 
ranges from 20 to 2000 Hz. 


TR-290 Random vibration test items shall be subjected 
to random vibration along each axis for one minute 
Sach. 


TR=-29) Random Vibration Lest cualiurication: and 
acceptance test levels will be determined in 
accordance with GSFC=SID—7000. 


TR-292 The mass properties of the integrated 
spacecraft shall be determined by measurement. 


TR-293 The following mass properties shall be 
determined: 


e Weight 

e Center of gravity 
e Moment of inertia 
e Balance 
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TR-294 Subsystem qualification tests shall be 
performed for each mechanical operation. 


TR-295 The integrated spacecraft shall be tested to 
demonstrate that each mechanical device is installed 
correctly and that there are no interference 
problems that will adversely affect the mission. 


6.2 Electromagnetic Compatibility Verification 
Requirements 
TR-296 Radiated emission tests shall be performed on 
spacecraft transmitters to identify electro-magnetic 
interference. 


TR-297 The integrated spacecraft shall be tested for 
stray magnetic fields which may affect the on-board 
Maqgnelomerers. 


6.3 Electrical Function Verification Requirements 
TR-298 Electrical interface tests shall be performed 
on each component and subsystem prior to integration 
to verify that interface signals follow the correct 
Signal path and are within acceptable limits. 


TR-299 Electrical harnesses shall be tested to verify 
proper routing, impedance, isolation, and 
workmanship prior to integration. 


TR-300 An aliveness test shall be performed prior to 
and following integration to verify that the 
component or subsystem is functioning. 


TR-301 A comprehensive performance test (CPT) shall 
be CONGUCTEd On. Gach Component and subsystem 
following environmental testing to demonstrate that 
components meet performance requirements within 
allowable. Tolerances . 


TR-302 CPT shall be conducted at the hot and cold 
extremes of the thermal-vacuum test for both maximum 
and minimum input voltage. 


6.4 Vacuum and Thermal Verification Requirements 
TR-303 All components and subsystem assemblies shall 
be subjected to thermal-vacuum tests that 
demonstrate function at temperatures ten degrees 
higher and lower than expected flight temperatures. 
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TR-304 The integrated spacecraft shall be subjected 
to thermal-vacuum tests that demonstrate function at 
temperatures five degrees higher and lower than 
expected flight temperatures. 


TR-305 Thermal-vacuum tests shall, at a minimun, 
subject hardware to four complete thermal cycles. 


TR-306 Thermal-vacuum tests shall incorporate a 
period Lor OCul-Cassind. 


TR-307 CPT shall be performed at each hot and cold 
soak. plateau OL a@ thermal cycle. 


6.5 Optical Calibration Requirements 
TR-308 Spatial edge response shall be characterized 
based on measurements at the integrated payload 
level, before and after vibration testing and across 
the entire field of view in all bands. 


TR-309A stray light model shall be developed that 
includes the entire optical system including 
baffles, detectors and portions of the satellite bus 
that may reflect light into the sensor. 


TR-310 The radiometric response of detectors shall be 
characterized across the expected operating 
temperature range of the payload. 


TR-311 The payload shall be characterized to ensure 
that it will meet absolute radiometric accuracy, 
pixel-to-pixel uniformity and radiometric stability 
in expected orbital conditions. 


TR-312 The signal to noise ratio of all detectors 
shall be characterized. 


TR-313 The baseline 1/f noise parameters for all 
imaging detectors shall be characterized. 


TR-314 The coherent noise of the integrated payload 
shall be characterized. 


TR-315 The dark level coherent noise of the 
integrated payload shall be characterized. 


TR-316 Dead, inoperable, and out-of-spec detectors 
Shall be identified and recorded. 
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TR-317 Alignment of the telescope optical axis 
relative to the spacecraft shall be measured. 


TR-318 Degradation of image quality due to internal 
spacecraft vibration shall be characterized. 


TR-319 Degradation of image quality due to spacecraft 
motion shall be characterized. 


TR-320 Alignment and focus changes to the optical 
path due to thermal expansion or contraction shall 
be characterized. 


TR-321 Aberrational variations from design to 
production shall be measured and characterized. 


TR-322 Variations in detector response shall be 
characterized through two out-gassing cycles. 
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1 PURPOSE 

This contamination control plan describes the requirements 
and procedures for the environmental management of the 
TINYSCOPE spacecraft. This plan is applicable during all 
phases of development to include fabrication, assembly, 
integration and test, and transportation and storage. 


2 SPACECRAFT CONTAMINATION SOURCES 

Contamination of a spacecraft may occur at anytime from the 
beginning of individual component fabrication through 
launch and into the spacecraft’s service life. Table l 
below lists the spacecraft’s development cycle and the 
contamination sources that must be guarded against in each 
phase. 


Table 1. Contamination Sources for Spacecraft. Taken 
from (Contamination Control Plan for Midshipman Space 
Technology Applications Research MidSTAR)-1 Spacecraft, 22 
June 2004.) 


Development Molecular Particulate 
Phase 


Fabrication materials out-gassing, | shedding, flaking, metal 
machining On1e, ||) chips, Tidiige, o11° Prellouc,; 
Fingerprints, air | personnel 
fallout 


Assembly & | alr fallout, out= || aa fallout, personnel, 
Integration gassing, personnel, | soldering, drilling, bagging 
cleaning, solvents, | material, shedding, flaking 
soldering, lubricants, 
bagging material 


Test ei Fallout, out- | air fallout, personnel, test 
gassing, personnel, test | facilities, purges, shedding, 
facilities, purges flaking, redistribution 

Storage bagging material, out- | bagging material, purges, 
gassing, purges, | containers, shedding, flaking 
containers 

Transport bagging material, out- | bagging material, purges, 
gassing, purges, | containers, Vibracion, 
containers shedding, flaking 

Launch Site bagging material, air | bagging material, air 
Fel out, out-gassing, | fallout, personnel, shedding, 
personnel, purges flaking, checkout activities, 

other payload activities 





LS 


Project TINYSCOPE 


NACL10-— 


Contamination Control Plan | og-r 


Launch/Ascent out-gassing, venting, | vibration and/or 
engines, companion | redistribution, venting, 
payloads separation | shedding, flaking 
maneuvers 

On-Orbit Out—-dassing, UV | spacecraft cloud, 
interactions, atomic | micrometeoroid & debris 
oxygen, propulsion | impingement, material 
systems erosion, redistribution, 

shedding, Plakiiad, 
operational events 





3 CONTAMINATION CONTROL REQUIREMENTS 

In general the assembly and integration of the spacecraft 
will take place ina Class 6 (ISO) clean room. When 
testing or transportation requires the spacecraft to leave 


the clean environment, it should be bagged. Hardware that 
1S not being actively used or worked on should be covered 
even when in the clean room environment. Hardware should 


remain surface clean in visible light at all times. 


3.1 FABRICATION, ASSEMBLY, & INTEGRATION 
Components of the spacecraft may be fabricated in 
uncontrolled environments. This does not preclude the need 
for contamination controls. These parts should still be 
surface clean at all times and should be bagged whenever 
possible. Prior to entry into the clean environment, each 
component will be cleaned thoroughly with a compatible 
solvent and will be inspected. 


During the assembly phase, all parts will be stored and 
assembled in the clean room. All test and support 
equipment will be cleaned prior to entry to the clean room 
and will be kept to the same standard of cleanliness as the 
spacecraft components while in the room. During operations 
that require soldering or the application of lubricants, 
contaminants should be removed immediately after the 
operation using an appropriate solvent. Areas that will 
become inaccessible due to assembly should be thoroughly 
cleaned and inspected prior to the assembly. 


3.3 TESTING & TRANSPORTATION 
Generally, contamination requirements during testing and 
transportation are the same as in previous phases. However, 
there may be cases where coverings must be removed to 
perform a test. In this case, personnel must don clean room 
clothing and gloves prior to handling the spacecraft. 
During periods of inactivity, the spacecraft will be 
draped. Out-gassing tests and vacuum bakeouts must be 
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followed immediately by a thorough cleaning of the 
spacecraft’s surfaces. After cleaning is complete, the 
spacecraft will be visually inspected. It will then be 
double bagged for transportation between facilities. The 
Spacecraft will be transported in a shipping container that 
has been be pre-cleaned to a visibly clean level. 
Temperature and humidity will not be monitored in the 
shipping container. 
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